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Chapter 1 

Summary 


The primary objective of this study was the development of a CFD (Computational Fluid 
Dynamics) based turbomachinery airfoil analysis and design system, controlled by a GUI 
(Graphical User Interface). The computer codes resulting from this effort are referred to 
as TADS (Turbomachinery Analysis and Design System). This document is the Final 
Report describing the theoretical basis and analytical results from the TADS system, 
developed under Task 10 of NASA Contract NAS3-27394, ADPAC System Coupling to 
Blade Analysis & Design System GUI, Phase II - Loss, Design, and Multi-stage Analysis. 

TADS couples a throughflow solver (ADPAC) with a quasi-3D blade-to-blade solver 
(RVCQ3D) or a 3-D solver with slip condition on the endwalls (B2BADPAC) in an 
interactive package. Throughflow analysis and design capability was developed in ADPAC 
through the addition of blade force and blockage terms to the governing equations. A GUI 
was developed to simplify user input and automate the many tasks required to perform 
turbomachinery analysis and design. The coupling of the various programs was done in 
such a way that alternative solvers or grid generators could be easily incorporated into the 
TADS framework. Results of aerodynamic calculations using the TADS system are 
presented for a multistage compressor, a multistage turbine, two highly loaded fans, and 
several single stage compressor and turbine example cases. 
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Chapter 2 

Introduction 


The aerodynamic design of turbomachinery airfoils is one avenue to improved engine 
performance, efficiency, and weight. Flow over turbomachinery airfoils is 3-dimcnsional 
(3-D) and viscous, with complicated flow features arising from shock waves, tip clearances, 
seal cavities, and cooling passages. Airfoil design also involves trade-offs between 
aerodynamic performance and requirements from stress, heat transfer, and other 
mechanical considerations. 

Traditional airfoil design approximates the 3-D flow by the quasi-31 ) flow in two 
perpendicular surfaces. One surface (SI) is in the blade-to-blade plane, and models the 
flow between the airfoils along a streamline in the meridional plane. The other surface 
(S2) is in the meridional plane, and models the radial distribution of flow. This is often 
called the throughflow analysis. The shape of the S2 surface is determined from the SI 
surface, and the shape of the SI surface is determined from the S2 surface. Convergence of 
the scheme can be achieved by iteration. Frequently, only one iteration is performed: the 
shape of the S2 surface is set from the airfoil shape and deviation and loss correlations, 
and the blade-to-blade conditions are determined from the S2 solution. This approach, 
introduced by Wu, [25], forms the basis of most turbomachinery airfoil design systems in 
use today. 

In the last few years, advances in CFD have enabled the use of 3-D codes to model 
the flow in turbomachinery blade rows. While modern CFD codes are capable of modeling 
the important features of these complicated flows, they are relatively slow and use large 
amounts of computer memory. Advances in computer technology and in solution 
algorithms are reducing the penalties associated with 3-D modeling, but routine design is 
still not practical with these tools. 

The advantage of 3-D modeling is obvious: more of the flow features are calculated, 
instead of being prescribed by correlations. The advantage of the traditional approach is 
that the airfoil can be designed as a stack of 2-D sections. There is a large experience base 
in the design of 2-D sections, and the associated design parameters are well understood. 
While 3-D analysis is common, 3-D design is not. Currently, 3-D design is accomplished 
by adjusting 2-D parameters in response to 3-D analysis. 

Recently, there has been considerable interest in updating the traditional design 
methods with modern CFD tools. There is a large gap in capability between the 
traditional design system and full 3-D viscous flow analysis. Much of this gap can be 
closed by incorporating the latest CFD techniques into the the traditional approach. For 
instance, the deviation angle in the blade-to-blade solution need not be specified if a 
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Navier-Stokes solver is used to compute the detailed flow solution for the airfoil section. 
Similarly, the effects of upstream total temperature and pressure profiles can be captured 
by a CFD based throughflow analysis. The effects of neighboring blade rows can also be 
economically modeled by an axisymmetric representation of the flow. The work of Spurr, 
[21], and Jennions and Stow, [10] in the 1980’s laid the groundwork for a number of 
recent publications. Yao and Hirsch, [27], developed a throughflow analysis based on 
CFD techniques. Damle, Dang, and Reddy, [6], developed a throughflow analysis with 
capability for both analysis and design. Sayari and Boles, [18], investigated the effects of 
different averaging procedures and blockage models in the throughflow analysis. 

These papers on throughflow analysis differ in focus, but follow a common strategy: 
the presence of the airfoil in the passage is modeled by body force terms and a blockage 
term. As the flow proceeds through the bladed region, the body forces model the change 
in swirl velocity imparted by the airfoil. The blockage term models the acceleration and 
deceleration of the flow, caused by the thickness of the airfoil in the passage and by 
deviation of the flow from the airfoil surface. Blade profile losses can be modeled through 
a source term similar to the body forces. As the flow proceeds through the bladed region, 
the source term removes energy from the flow such that a relative total pressure loss is 
achieved at the trailing edge. New models for body forces, blockage, and losses were 
developed in the ADPAC solver for this purpose. ADPAC is a 3-D Euler/Navier-Stokes 
analysis which is capable of performing axisymmetric calculations, [9]. 

Many throughflow papers also discuss a design mode where the aerodynamic end 
result is known and the required blade shape is desired. For this case, the general strategy 
is: make an initial guess for the blade shape and set the aerodynamic requirement for the 
blade row (e.g. prescribing the total enthalpy rise across a rotor). Then, iterate on the 
blade shape until the current solution matches the desired solution. Like the body forces 
and losses, the design mode method was developed and added to the ADPAC solver. 

Quasi 3-D blade-to-blade solvers have special features for solving flow between 
airfoils along a meridional streamline. These features include rotational terms, radius 
terms, and stream tube thickness terms. The radius and stream tube thickness terms 
differentiate a 2-D solver from a quasi 3-D solver. These terms allow the blade-to-blade 
flow to feel the effects of the changes in the meridional flow path. The radius terms 
account for the change in blade pitch associated with changes in radius, and the stream 
tube height terms account for the change in the distance between neighboring streamlines, 
RVCQ3D , [3] and [4], is a good example of a quasi-3D analysis. 

An alternative to a quasi 3-D solver is a fully 3-D solver with slip conditions on the 
hub and shroud endwalls. This can be done on most 3-D Navier-Stokes solvers that allow 
discrete boundary condition settings. Performing the blade-to-blade analysis using a 3-D 
solver has the disadvantage of requiring that every slice must be computed. However, the 
need for radius and streamtube thickness information is avoided and mass flow for each 
slice is properly matched for the blade row (mass flow in the quasi 3-D solutions can be 
affected by back pressure extrapolation errors). Additionally, many 3-D Navier-Stokes 
solvers (e.g. ADPAC [9]) have non-reflecting boundary conditions and convergence 
acceleration techniques that are essential for multistage calculations. 

The objective of the present work is to produce a turbomachinery airfoil design and 
analysis package built on the traditional approach, but using modern analytical 
techniques. This new Turbomachinery Analysis and Design System (TADS) is controlled 
by a Graphical User Interface (GUI), which simplifies user input and automates the many 
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required tasks. TADS couples a throughflow solver [ADPAC] with either a quasi-3D 
blade- to-blade solver (RVCQ3D) or a full 3-D solver with slip condition endwalls 
(B2BADPAC) in an interactive package. The coupling is done in such a way that 
alternative solvers or grid generators can be easily incorporated into the TADS framework. 
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Chapter 3 

Analysis Coupling 


A coupled throughflow and blade-to-blade analysis requires many steps, repeated 
iteratively. Figure 3.1 shows the work flow of a typical analysis. A converged analysis is 
achieved when the meridional streamlines are settled in the throughflow analysis and when 
the mean stream surface is settled in the blade-to-blade analysis. Each analysis provides 
the solution surface for the other, and iteration is required to determine the final shapes. 

In practice, only one iteration is required to achieve an acceptable solution in many cases. 

3.1 Solution Procedure 

Since the coupled analysis is an iterative procedure, there are two possible paths to begin 
a TADS solution: start with the blade-to-blade analysis, or start with the throughflow 
analysis. Which one to choose is a function of the airfoil shape design program and of user 
preference. In either case, there is some critical information which must be fabi h ated as 
an initial guess. 

The throughflow analysis requires a mean stream surface which is found from the 
blade-to-blade solutions, and the blade-to-blade solutions are performed along streamlines 
provided by the throughflow calculation. In the design mode, the throughflow solver itself 
creates the mean stream surface, but the coupling with the blade-to-blade analysis is the 
same. In the analysis mode, TADS begins with the throughflow solver, using the mean 
camber line and, optionally. Carter’s deviation angle rule to set the mean stream surface. 
For a design mode run, TADS begins with the throughflow solver using an initial guess for 
the mean stream surface and a set of aerodynamic design requirements. The throughflow 
solver then iteratively calculates a new mean stream surface such that the solution 
satisfies the aerodynamic requirements. 

The first step in the analysis mode is to acquire a , description of the airfoil and of 
the flow path. Certain aerodynamic quantities are also required, such as the upstream 
total pressure and temperature, upstream flow angle, and downstream static pressure. 
Typically, airfoil design programs specify the aerodynamic inflow and outflow quantities at 
discreet X and R locations on the leading and trailing edges, respectively. These 
quantities are arranged in the TADS aerodynamic data file. TADS follows this convention 
and extrapolates the required data to the upstream and downstream grid boundaries 
when required. Actually, only the throughflow analysis utilizes this aerodynamic, data, the 
blade-to-blade analysis takes its aerodynamic input by interpolation from the throughflow 
solution. The first step in the design mode is identical to the analysis mode except that 
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Figure 3.1: The coupled throughflow and blade-to-blade analysis is an iterative, multi-step 
process. 
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there is no initial airfoil description. The user generates the airfoil description by running 
the PREDESIGN module. PREDESIGN is also used to generate the complete blade rVg 
distribution which forms the basis for the design mode aerodynamic requirement. 

The second step is to generate a grid for the throughflow calculation. This requires 
the flow path and the meridional projection of the airfoil leading and trailing edges. In the 
design mode, if the user has not run PREDESIGN and no airfoil description exists, the 
leading and trailing edge X,R points from the aerodynamic data file are used. The 
axisymmetric grid generator used in TADS is TIGGC3D , which is related to TIGGERC , 
[15]. The output is a planar axisymmetric grid (i.e. it is a z-r grid only. 0 = 0 throughout) 
with grid lines coinciding with the leading and trailing edges. 

The third step is to run the throughflow computation using ADPAC. In the analysis 
mode, A DPA C requires as input: the grid, an input file containing controlling parameters, 
a boundary condition file, and a body force file. The grid must be modified (as described 
below) to conform to the shape of the mean stream surface in the bladed region. ADPAC 
forces the flow to be tangent to the grid in the bladed region, and computes the body 
forces required for flow tangency. The throughflow computation for the design mode 
requires the same files as the analysis mode plus a rVg distribution file. The ADPAC 
design mode iteratively updates the mean stream surface until all points in the blade 
region match the rV e distribution. ADPAC also has the option of modeling profile losses 
through the blade row. This option requires an extra file specifying the radial distribution 
of total pressure loss coefficient at the blade trailing edge. The method of specifying 
distributions (%span, %massflow, etc.) for loss coefficient (and most other quantities in 
TADS ) is explained in more detail in the TADS User’s Manual [11]. ADPAC uses the 
loss coefficient distribution to generate a source term that, when applied to points inside 
the bladed region, creates a drop in relative total pressure from leading to trailing edge of 
the blade row. A separate program is used to apply the mean stream surface shape to the 
grid from TIGGC3D. Another program is used to generate the boundary condition file, 
and the input file is constructed from the GUI. The user sees only the input panel on the 
GUI; the rest is transparent to the user. After either an analysis or design mode 
computation is performed, some checking is appropriate for convergence and for solution 
quality. The remaining steps in the TADS solution procedure are the same for both the 
analysis and design mode. 

The fourth step is to find the meridional streamlines from the throughflow solution. 
Only the number and distribution of the streamlines are required as input. The 
streamlines are found by accumulating flow from hub to tip along radial grid lines. The 
flows are then normalized, and contours are traced from inlet to exit at values of constant 
mass flow. 

The fifth step is to slice the airfoil along the meridional streamlines. This step 
requires no new input. The output of this step are the airfoil sections along the meridional 
streamlines which are to be used in the blade-to-blade analysis. 

The sixth step is to generate blade-to-blade grids for each airfoil section. The input 
is controlled by the GUI, and includes parameters for the grid size, upstream and 
downstream extents, number of blades, etc. 

The seventh step is to run the blade-to-blade solver for each airfoil section. This 
step is typically the most time consuming part of the analysis. The input is c ontrolled by 
the GUI, and includes parameters for the number of iterations, the size of time step, 
turbulence model choices, etc. These solutions should also be checked for convergence and 
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quality. 

The eighth and final step is to compute the mean streamline between the airfoils for 
each airfoil section. This involves stacking the quasi 3-D solutions into an equivalent 3-D 
file, finding streamlines on the blade-to-blade surfaces, and interpolating the shape onto 
the throughflow grid. This step can be omitted if no iteration is to be performed. 

These eight steps can be repeated, iteratively, until the mean stream surface used in 
the throughflow analysis and the radial streamlines used in the blade-to-blade analysis are 
settled (i.e. not moving between throughflow and blade-to-blade analyses). 


3.2 Programming Philosophy and Standards 

The TADS system is an amalgamation of many different programs under a single GUI. 
One of the objectives in the development of TADS was to enable new modules to be added 
to perform any of the tasks without major coding effort. That is, additional choices for 
grid generators or flow solvers could be added in a modular fashion. The biggest obstacle 
to modularity is that each program has its own set of standards. Each has its own input 
and output format, its own coordinate system, its own non-dimensionalization, etc. 

One approach is to make each program a subroutine called by the GUI. This way, 
all data could be passed internally and the system would be tightly coupled. There are 
many disadvantages to this approach, however. First, each code would require significant 
modification to be integrated into the GUI. These modifications would need to be remade 
each time a new release of the code was received. Second, if each code is a subroutine of 
the GUI, it is difficult to send calculations to a remote machine to take advantage of faster 
platforms. Finally, each code would no longer work as a stand-alone product. The user 
would be forced to use the GUI to be able to access the code. Many of these codes can be 
used for purposes outside of TADS , and it is advantageous to retain access to these unused 
features. 

A second approach is to leave each code as a stand-alone module, and either modify 
the I/O of the code to conform to some standard, or write conversion modules into the 
input generators and post-processors for each code. Since the grid and solution files are 
the only link between one program and another, it is simpler to modify the I/O than to 
write special conversion routines. TADS follows this approach. The disadvantage to the 
TADS approach is that there are many files created during an analysis, and the directory 
can become cluttered. Although the clutter is unfortunate, these files provide a built-in 
restart capability for the analysis. 


3.2.1 File Naming Convention 

The files created or used by TADS use the casename.extension file name convention 
adopted from ADPAC. The user specifies a case name for the problem, and each file 
needed by TADS assigns a unique extension to it. This way, multiple airfoils could be run 
in the same directory. There is also much less confusion about which files were created by 
TADS. Some programs, notably the grid generators and quasi 3-D solvers expect files with 
specific names for input and output. These files do not follow the convention adopted for 
TADS. This is not a serious problem unless multiple runs of the same program must be 
made in the same directory. Multiple runs woidd require multiple files with the same 
name, resulting in overwritten data or confusion about the contents of files. While it 
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would be possible to write scripts to rename or symbolically link files to the expected 
names, it is clearer and simpler to create subdirectories to contain these files. TADS 
creates a subdirectory for each blade-to-blade section to be analyzed. Within the 
subdirectory, some files do not conform to the naming convention, but confusion is 
avoided because the subdirectories themselves are named descriptively. 


3.2.2 Data Standards 

All files used by TADS are either ASCII text, or binary files written with the SDB library. 
SDB is a library of I/O routines which create platform independent binary data. On each 
platform, an SDB library is available to perform the necessary conversions. Using SDB, 
any platform can read binary data created by any other platform. Supported platforms 
include Cray, Silicon Graphics, IBM RS/6000, Sun, etc. The binary data structure of SDB 
is equivalent to reading and writing binary data in C on a Silicon Graphics workstation. 
SDB is documented in [24]. All TADS files are platform independent, so any program 
task can be performed on any supported machine without loss of generality. 

Most of the binary files used by TADS are geometry or flow data files. All geometry 
or flow data files are written in PL0T3D format using SDB. Specifically, all files are 3-D, 
whole, multiple grid files, in accordance with the definitions in [23], pp 162-165. 

3.2.3 Coordinate Systems 

While PLOT3D files are Cartesian, many of the modules within TADS use cylindrical 
polar coordinates. Most TADS modules read the Cartesian coordinates and convert 
immediately to cylindrical polar for the internal calculations. All output files are 
converted back to Cartesian for output. 

In the conversion between cylindrical polar and Cartesian coordinates, there are two 
common orientations: place 6=0 along the Y axis, or place 6=0 along the Z axis. The 
standard orientation in TADS places the R axis in cylindrical coordinates along the Z axis 
in Cartesian coordinates when 6=0. This is, in effect, a right handed system in which 
(X.i9.R) corresponds to (X,Y,Z) (where x is the axis of rotation and is positive in the 
direction of flow into an axial machine. Some TADS modules, notably TIGGC3D , 

ADPAC, and B2BADPAC operate with a left handed coordinate system. Since only two 
dimensions are used for TIGGC3D and ADPAC , it is relatively unimportant except that 
the Cartesian orientation of a TIGGC3D grid is inconsistent with the TADS right-handed 
standard. The TIGGC3D mesh is modified by the body force calculator, which then sets 
the 6 distribution according to the TADS standard. The full 3-D left-handed meshes used 
by B2BADPAC are also inconsistent with the TADS standard. However, each 
B2B ADPAC grid is placed in a casename . row . # subdirectory (where # denotes the blade 
row number for the B2B ADPAC run) to avoid any convention problems. 

The standard coordinate system and orientation make it simple to graphically 
compare the input and output of the various codes. For example, the user can examine 
the difference between the axisymmetric average stream surface computed from the 
blade-to-blade solver and the distribution set according to the mean camber line. It is also 
possible to verify that the mean camber line lies properly in the original airfoil 
description. Most of the modules would perform equally well with input files in another 
orientation, but verification would be more difficult. The coordinate system standard was 
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adopted so that, the geometric information used in each step of the analysis could he 
compared graphically without a coordinate transformation. 

3.2.4 Shared Routines and Data 

There are many routines which are shared between TADS modules. There are also many 
modules which need the same data structures (common blocks, etc) as other TADS 
modules. These routines (in the form of a TADS library) and include files are kept in a 
separate subdirectory which is accessible by all TADS modules during compilation. This 
was done to eliminate duplicate (and possibly conflicting) copies of subroutines and 
include files. The common routines are bound into a library which is linked into each of 
the TADS modules. The include files are made available to the TADS modules through 
symbolic links. Each module has a makefile, to build the executable from the source code. 
Each makefile has a dependencies section which causes routines to be recompiled if an 
include file has been updated. The dependencies section insures that all object code will 
be up to date before an executable is made. These practices dramatically reduce the 
possibility of data errors in the codes. Each module uses the same data structures, and 
only one copy of each routine or include file exists. 

3.3 Input Requirements 

For the analysis mode, the TADS system requires four things as input: a case name, a 
Cartesian description of the airfoil, a description of the meridional flow path, and 
aerodynamic data. For the design mode, TADS requires only the casename, flowpath 
description, and aerodynamic data. For modeling losses in either the analysis or design 
mode, a file containing the radial profile of total pressure loss coefficient at the trailing 
edge of the blade row is required. The airfoil is input as a 3-D surface in two parameters. 
One parameter wraps clockwise (looking from tip to hub) around the airfoil from trailing 
edge back to trailing edge to form a closed path. The second parameter runs with the 
span of the airfoil. The resulting definition is very similar to the blade surface mesh points 
of an O-grid. The meridional flow path is defined by two lines in the (A, R) plane. The 
file contains two sequential sets of (X, R ) column data. The first set is the hub definition 
running monotonically from smaller to larger x values. The second set is the casing 
definition, also in monotonically increasing x. The aerodynamic data contains tables of 
information at the leading and trailing edges. These tables consist of radial profiles of 
total temperature and pressure, static pressure, and Mach number components. This file 
also contains the ratio of specific heats,' the number of blades, and the tangency points of 
the airfoil. The tangency points are those points in the airfoil description which denote 
where the leading and trailing edges join the pressure and suction surfaces. The 
TADS User’s Manual [11] provides details on the contents and organization of the input 
files. All other information needed by TADS has either a default value which can be reset 
in an input panel, or is generated by another part of the analysis. 

It should be noted that, since x values in the casing definition must be 
monotonically increasing, TADS as a whole is limited to axial turbomachinery geometries. 
Much of this limitation is present because the splining and interpolation routines used to 
transfer between the throughflow and blade-to-blade modules require that x,r distributions 
are single-valued functions. Also, making provisions for radial geometries would add extra 
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complications to an already complex design system. Therefore, any capability to examine 
radial machines will require a substantial coding change in a future release of TADS . 
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Chapter 4 

Development of Program Modules 


The TADS system is comprised of many independent modules which are linked together 
by the GUI. This chapter details the development of each module, in the order they are 
normally encountered in an airfoil analysis. Many of these modules were developed 
specifically for the TADS system, while others were provided. The user is referred to 
existing documentation for the provided programs for additional details. 

One of the requirements under Task 10 of NAS3-27394 is to modify TADS for 
multistage computations. Many of the component modules under the previous 
TADS development contract (Task 18 of NAS3-25950) had been hardwired to only 
perform single blade row computations. The Task 18 version of TADS is henceforth 
referred to as “single stage” TADS or the TADS 1.0 version. For many modules, the 
extension to a multistage environment was rather straightforward and no extra details are 
required. For some modules, however, the multistage modifications prompted a change in 
theoretical or programming philosophy. Where these multistage changes are critical, 
comparison will often be made with TADS 1.0. 

In this chapter, reference is made to the TADS design mode pre-processor 
PREDESIGN and post processor POST. These are TADS modules, but because they are 
so graphically intensive, their full description is given in the chapter on GUI development. 


4.1 INTIGG 

INTIGG is an input generator for TIGGC3D. INTIGG takes its input from the 
casename . tdsaxi file, the blade description file, and the flow path files. The 
casename .tdsaxi file is created by the GUI, and contains the user choices entered in the 
TIGGC3D input panel. Included in this information are the grid size, indices of the 
leading and trailing edge, grid extents as a fraction of the axial chord, and whether or not 
to apply Carter’s deviation angle rule. The Carter’s rule trigger is ignored by INTIGG 
but is used by another program module. If the casename .tdsaxi file does not exist at the 
beginning of a TADS run, it is created using default, values. 

INTIGG requires an axisymmetric representation of the blade definition, which 
consists of the shape of the leading and trailing edges in the meridional plane. The 
meridional projection of the leading and trailing edges is computed simply by locating the 
minimum and maximum axial extents of the blade description on each defining slice. 

It should be noted that this procedure may not yield the same result as taking the 
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minimum and maximum values from a grid generated on the same surface, Figure 4.1. 
The true extrema could be yet a third set of values. There is no requirement that the 
airfoil definition explicitly define the minimum or maximum axial extent of the airfoil, so 
small errors are introduced by using the the largest and smallest values to represent the 
meridional projection of the leading and trailing edges. 

From the standpoint of the throughflow analysis, the error introduced is probably 
inconsequential. However, from a numerical standpoint, a number of potential problems 
arise. In the TADS system, there are many representations of the airfoil: the definition, 
the airfoil slices on the meridional streamlines, the blade-to-blade grids, the meridional 
projection in the throughflow grid, etc. Data is often transferred between the various 
representations by interpolation. Because the endpoints of the domain are different in 
each representation, interpolation errors are possible at the endpoints. This is of some 
consequence, since the largest flow gradients are frequently at the leading edge. TADS 
modules minimize the error introduced by interpolating along grid lines where possible, 
and by using a normalized airfoil chord when necessary. This essentially says that the 
leading edge in one representation is equal to the leading edge in another representation, 
regardless of variations in the (X, Y, Z) data which describes it. 

It should noted here that a great deal of interpolation error can be avoided by 
providing an adequate number of defining points for the leading and trailing edges. For 
most of the cases examined with TADS , the leading edge radius (the half circle zone near 
the minimum x point in Figure 4.1) is defined by 15 to 20 points. Trailing edge radii have 
a similar point density. 

INTIGG also finds the intersection points between the leading edge and the flow 
path, and the trailing edge and the flow path. Again, the airfoil description does not 
necessarily conform to the flow path; the description may not even span the entire flow 
path. Consequently, INTIGG finds the intersection points between the airfoil and the flow 
path by locating the intersection of splines through the given data, Figure 4.2. The 
upstream and downstream boundary locations of the grid axe then computed using the 
hub axial chord, and the user specified fractional extent. When preparing data for a 
TADS run, care must be taken that blade leading and trailing edge hub and shroud points 
are reasonably close to the accompanying flowpath geometry. Otherwise, INTIGG will 
have to perform substantial extrapolation that will yield questionable blade/flowpath 
match points. 

When running a design mode calculation, there is a possibility that the user has not 
run the PREDESIGN module and thus an airfoil description does not exist. As a safety 
check, if INTIGG cannot find an airfoil description file (casename.tdsblad), then the 
leading and trailing edge axial and radial geometry points from the aerodynamic data file 
are used. This substitution is usually acceptable, but running PREDESIGN is always a 
better method for starting a design mode run in TADS . 

For a given blade row, TIGGC3D treats the throughflow grid as three blocks: 
upstream of the airfoil, within the airfoil row, and downstream of the airfoil. INTIGG 
initially defaults to equal axial spacing of grid nodes within each of the three blocks (This 
can later be changed in TIGGC3D). 

In a multistage case, INTIGG attempts to preserve the upstream and downstream 
extents specified by the user in the GUI input panel. However, if these extents result in an 
row-to-row interface which is less than 5% chord away from the neighboring blade row, 
INTIGG will force the row-to-row interface to lie half way between the adjacent rows. 
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Representation of Geometric Features on an Airfoil 



0 Minimum X values from airfoil definition and grid are different 

• Actual leading edge location may not exist in either description 

Figure 4.1: The various interpretations of geometric features must be carefully accounted for 
in the program modules. 
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Meridional Representation of Airfoil in Throughflow Grid 


Leading edge projected from definition 


Upstream grid- 
boundary 


-* V f-* 





Flowpath from definition 


Detail of intersection 



Downstream grid- 
boundary 


Trailing edge projected from definition 


Intersection point found from intersection of splines 
Figure 4.2: The grid extents and airfoil projection are computed from the definitional surfaces. 
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More details about controlling the row-to-row block boundary location can be found in 
the User’s Manual in the Input Panels chapter. 

The spanwise spacing is determined by a user defined trigger which indicates 
whether a viscous or inviscid throughflow analysis is to be performed. The default is an 
inviscid analysis, and INTIGG prescribes uniform spacing in the spanwise direction. For a 
given row, TIGGC3D creates the final grid as a single block. This single block is then 
written (with the other blocks in a multistage case) to a 3-D, whole, multiple grid, SDB 
PLOT3D grid file. 

4.2 TIGGC3D 

TIGGC3D is a 2-D/3-D grid generator for turbomachinery applications. It is a multiple 
block H-type grid generator with algebraic and some elliptic capabilities. TIGGC3D was 
originally designed to model multi-row core/bypass flows, and the input structure reflects 
this heritage. The TADS system uses TIGGC3D , version 5.2, as a 2-D axisymmetric grid 
generator for a single block algebraic grid. This capability is also found in a related code 
TIGGERC , and is documented in [15]. TIGGERC was merged with TIGGC3D by NASA 
to reduce the code maintenance burden and to provide more capability in a single code. 
TIGGC3D is the only module aside from the GUI itself which uses graphics in the TADS 
system. TIGGC3D is also the only graphical module in TADS which does not use the 
Motif library under X-Windows. 

The graphics in TIGGC3D use the Forms Library, [17] which, in turn, is 
programmed in Silicon Graphics GL. There also is an X-Windows version of the Forms 
library called XForms, or the Forms Library for X [26]. A TIGGC3D executable can be 
made with either Forms or XForms, but only the Forms executable has the intended look 
and feel. 

Unfortunately, some of the drawing routines are programmed directly in GL. This is 
a limitation to porting TIGGC3D to other platforms which do not support the SGI GL 
graphics library. IBM offers a GL graphics board on its RS6000 systems, but the IBM 
implementation is not fully compatible with the SGI implementation. While the 
TIGGC3D executable can be made on an IBM workstation with a GL board, the graphics 
do not perform properly on the IBM. 

TIGGC3D has a batch mode option, which does not call the graphics routines. This 
option is particularly useful on IBM R.S/6000 systems where an executable can be made, 
but the graphics are not functional. 

Other than the graphics related issues discussed above, the TIGGC3D code is used 
as received from NASA Lewis. Other versions of the code can be substituted, if necessary, 
without modification. 

4.3 ADPAC Input Generation 

The ADPAC throughflow analysis mode requires four files as input: a grid, a boundary 
condition file, a body force file, and an input file. The ADPA C throughflow design mode 
requires, in addition to the analysis mode files, a rV 8 definition file. Modeling losses in 
either the analysis or design mode requires a total pressure loss coefficient file. 

The input file is created by the Gil based either on user choices in an input panel, 
or default values. The input file consists of execution control parameters and reference 
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conditions. All ADPAC input parameters are described in [8] or in the TADS User’s 
Manual [11]. Using the default parameters normally results in a successful throughflow 
analysis. However, modifying the CFMAX variable (which is related to the CFL number), 
number of time steps, and body force under-relaxation parameters are particularly useful 
for difficult cases. 

The grid file is created by T1GGC3D, and must conform to the ADPAC naming 
convention: casename .mesh. If the batch version of TIGGC3D is used, the casename is 
set by default, but in the interactive mode, the user must type in the proper name when 
prompted. 

The program ADPACBC prepares the boundary condition file for ADPAC. 
ADPACBC uses the axisymmetric grid, the user-supplied aerodynamic data, and the flow 
path description as input . ADPAC requires reference quantities which are used for 
non-dimensionalization. These are prescribed as the hub values of total pressure, total 
temperature and Mach number specified in the aerodynamic data file. There is an implicit 
assumption that the hub values of total pressure and temperature are close to the free 
stream values and this is generally true when inlet profile data is acquired from a 
streamline curvature code. Since these quantities are used only for non-dimensionalization 
purposes, though, they do not need to be the exact freestream values. For a throughflow 
calculation, the A DPA C boundary conditions are depicted in Figure 4.3. For a multistage 
case, only the first block requires iidet boundary conditions and only the last block 
requires exit boundary conditions. The communication between adjacent blocks is 
accomplished through the MBCAVG boundary specification (see [8] for more details). 

The implementation of the 1-D boundary condition extrapolation required careful 
attention to geometric issues. For example, the user specifies radial profiles of total 
pressure, total temperature and Mach number components at the leading edge. These 
profiles are accompanied by the appropriate radii. A DPACBC extrapolates the data from 
the leading edge (as defined by the aerodynamic data) to the upstream boundary of the 
grid. It is not correct to ratio the areas from the grid and the aerodynamic data file to 
enforce the conservation of mass. Because there is no requirement for the user data to 
span the flow path at the leading and trailing edges, the resulting areas may not be 
correct. This problem was solved by computing the normalized distribution of the points 
on the radial profile based on areas. This normalized distribution is then applied to the 
leading edge and the inlet boundary as defined by the grid. The ratio of areas is 
performed using only areas based on the grid, ensuring self-consistency. The exit static 
pressure is computed using similar techniques. 

The body force and rVg definition file are created by the BODYF module discussed 
in the next section. The total pressure loss coefficient file is created by the user. A 
complete description of this file can be found in the TADS User’s Manual [11], 


4.4 BODYF 

In the analysis mode, BODYF creates the body force file for ADPAC and applies the 
mean stream surface shape to the axisymmetric grid. The input files for BODYF are the 
axisymmetric grid, the aerodynamic data file, the airfoil definition, and the mean stream 
surface file from ME A NS L if available. In the design mode, BODYF creates the ADPAC 
body force file, generates an initial guess for the mean stream surface, and creates the 
ADPAC rVg definition file. The input files are the axisymmetric grid, the aerodynamic 
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Specification of ADPAC Boundary Conditions 



Solid Surfaces (Inviscid or Viscous) 


Trailing 

Edge 


Inlet 

Boundary 


Leading 
Edge 


Use MBCAVG 
(mixing plane) 


• User specifies aerodynamic data at the leading and trailing edges as 
radial profiles. 

• ADPACBC extrapolates the data to the inlet for the first block and to 
the exit for the last block. 


• Extrapolation is according to 1-D gas dynamics, conservation of mass 
and angular momentum. 

• Block interfaces use the ADPAC MBCAVG boundary specification. 


Figure 4.3: The ADPAC boundary conditions are set based on user supplied aerodynamic 
quantities and geometric considerations. 
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data file, and the rVg design file. The rVg design file is generated by the PREDESIGN 
module. BODYF is unique among the TADS program modules in that it expects to both 
read and write the axisymmetric grid file. There are no other program modules which 
modify a file read as input. 

In the analysis mode, BODYF has two possible methods of operation: one is to 
create a mean stream surface from the mean camber line and possibly Carter’s deviation 
angle rule, and the other is to interpolate a mean stream surface determined by MEANSL 
onto the axisymmetric grid. In either case, the blockage is computed and written to the 
body force file. In the design mode, the blockage and mean stream surface are generated 
in the same way as in the analysis mode. The rV 0 definition file is generated from data 
read in from the rVg design file. 

The blockage is defined at each grid cell center as the fraction of the total pitch 
open to flow. Except in the bladed region, the blockage is 1.0. In the blade region, the 
blockage is computed from the 0 values on the pressure and suction surface at a given A' 
and R. The difference between 9 values is subtracted from the pitch, and normalized by 
the pitch to arrive at the blockage value, A, as follows: 

_ Ops - Oss 
( 2ix/N) 

where N is the total number of blades in a given blade row. 

4.4.1 Airfoil Thickness Determination 

The airfoil description and the axisymmetric grid may have slightly different locations for 
the leading and trailing edges. To avoid interpolation difficulties between the different 
airfoil representations, a new procedure was developed. Figure 4.4 shows an axisymmetric 
grid and the blade geometry description projected on the axisymmetric plane. Both grids 
are defined in two parameters, where the indices i and j run in the axial and radial 
directions respectively. To determine the blade thickness values for the axisymmetric grid 
it necessary to interpolate the circumferential coordinate, 6 , from blade geometry 
description. 

The first step is to define a reference line which joins the leading and trailing edge 
points on the j=constant curves in the axisymmetric grid. Next, the radial differences 
between the reference line and the j=constant curve at each i station are computed. This 
radial difference is then splined versus the fractional distance from the leading edge 
(distance=0.0 at the leading edge point and 1.0 at the trailing edge point) using a cubic 
spline. The next step is to define the j=constant curves in the axisymmetric grid on the 
projection of the blade geometry in the axisymmetric plane. Again, radial differences are 
computed from the same reference line used in the axisymmetric grid. This time though, 
they are calculated along i=constant curves at each j station. At each station, the 
fractional distance from the leading edge point is used to lookup the radial difference from 
the spline formulated for the axisymmetric grid. A difference of the radial differences is 
then calculated. A parameter is formulated along the i=constant curves which is the 
linear distance between ordered points. The blade coordinates (X and 0) are splined 
versus this length parameter and the length parameter is splined versus the difference of 
the radial differences. Where the difference of the radial differences is zero, the j=constant 
curves in axisymmetric grid intersect the blade geometry. Using this fact, the length 
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parameter is easily determined from the spline of the differences versus the length 
parameter. The corresponding blade coordinates art: looked up from their respective 
splines versus the length parameter. The final step is to formidate a spline of 6 versus the 
fractional distance from the leading edge. This spline is then used to interpolate 0 onto 
the axisymmetric grid. For generality and possible future modifications to TADS , the 
procedure has also been coded to handle radial turbomachinery using a similar technique . 

4.4.2 Mean Stream Surface Determination 

The mean stream surface between airfoils is approximated by the mean camber line, in the 
absence of a computed stream surface from MEANSL. Originally, the mean camber line 
was approximated by the average of the 6 values on the airfoil surface used foi 
determining blade thickness. An improved procedure was later incorporated which 
computed the mean camber line as the locus of the centers of circles which are tangent to 
both the pressure and suction surface. The difference between these descriptions can be 
significant, especially near the leading and trailing edges, Figure 4.5. Of particular 
importance is the fact that the mean camber lined defined by a circumferential average 
passes through the minimum X point, and not through the true leading edge. The result 
is that the leading edge metal angle is distorted, especially at high setting angles, leading 
to incidence problems in the throughflow analysis. 

The new procedure finds circles which are tangent to both surfaces at a number of 
axial locations. The airfoil is considered to be made of three parts: the body, and the 
leading and trailing edges. The beginning and end of the body of the airfoil is determined 
from the tangency points. Only the body of the airfoil is used to determine the mean 
camber line. The leading and trailing edge angles are extrapolated from the spline of the 
mean camber line through the body of the airfoil. Using this procedure, a good 
representation of the mean camber line can be found, even for airfoils with non-circular 
leading and trailing edges. 

Because the primary goal of the design mode in ADPAC is to arrive at a mean 
stream surface shape from the imposed rV$ distribution, it is actually not necessary to 
apply a stream surface shape to the axisymmetric grid generated by TIGGC3D. However, 
if the initial shape of the ADPAC mesh is close to the final shape, then convergence speed 
and stability of the design mode throughflow calculation will be enhanced. Hence, an 
initial guess of mean stream surface shape is made using the blade definition generated by 
PREDESIGN. 

4.4.3 Carter’s Rule 

Carter’s deviation angle rule is often used in the design of compressor blades to account 
for the deviation of the mean stream surface from the mean camber line. Accounting for 
deviation with Carter’s rule leads to more realistic throughflow solutions. 

Carter’s deviation-angle rule is a correlation which relates the deviation angle to the 
airfoil camber, solidity, the blade-chord angle (the angle between the blade chord line and 
the axial direction), and an experimentally derived factor. The details of Carter s rule are 
presented in [12]. 

Carter’s rule specifies the deviation at the trailing edge, but does not specify the 
growth of the deviation along the airfoil chord. In the current work, the distribution is 
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Figure 4.4: The airfoil thickness is determined by an interpolation procedure which handles 
differences in airfoil descriptions. 
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NASA Rotor 67 Hub Section 
Mean Camber Line Representations 



Figure 4.5: The procedure for determining the airfoil mean camber line strongly affects the 
incidence angle. 
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patterned after the method used in other design systems. Namely, the growth of deviation 
is specified as a parabola of the form 

y = Ax 2 + Bx + C 

where x is the distance from 25% chord, y is the deviation, and the coefficients A, B, and 
C are determined by the boundary conditions: 

at x = 0 (25 %chord), y = 0 
at x = 0.75 (75 %chord), y — trailing edge deviation 
at x = 0, y' = 0 

From 75% chord to the trailing edge, the deviation remains constant. This distribution is 
smooth and grows strongly near the trailing edge, as is observed in experimental airfoil 
data. 


4.4.4 Mean Stream Surface from MEANSL 

The mean stream surface description found by MEANSL is defined only along the 
meridional streamlines from the blade- to- blade analyses. This description must be 
interpolated onto the full axisymmetric grid, which normally has more points in the radial 
direction. The interpolation is one-dimensional because the points in the MEANSL 
description of the mean stream surface are aligned with the radial grid lines in the 
axisymmetric grid. The interpolation assumes that the hub and shroud adhere to the 
same flow path. A linear interpolation is performed along the radial grid lines, using 
radius as the common parameter between the two representations. 


4.4.5 rVg Definition Determination 

In the design mode, the rVg definition determines the amount of work (rotors and blades) 
or turning (stators, vanes, IGV’s) at each point in the bladed region. BODYF reads in the 
leading and trailing edge rV 0 profiles and the rVg axial distribution information from the 
rVg design file, casename . rvtdesign. Once read in, the leading and trailing edge profiles 
and axial distribution are interpolated to the axisymmetric grid leading and trailing edge 
X,B points. Then, along each j-constant grid line, the local cell-centered rV e values are 
calculated using a linear or quarter sine wave distribution given by: 


{'rVg) x = {rVg)tE + A(rVfl) * sin 


( \ (x-xle) 

\ L C axial 


1 POWER\ 

) 


where x is axial distance, the LE subscript denotes a quantity at the leading edge, and 
Caxial is axial chord. POWER is the axial distribution value from the rVg design file. A 
POWER value of 0.0 forces a linear distribution like: 


(rV$) x = ( rV e ) LE + A (rVg) * 


(x - Xle) 

Caxial 


The resulting rVg distribution is written to a casename .rvt .# where # denotes the 
associated blade row. Currently, this file is written in ASCII text instead of SDB format 
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like most of the larger ADPAC input files. It was decided that, because the design mode 
was such a new method for ADPAC , the most critical input file should be readable for 
debugging purposes. 


4.5 ADPAC 

ADPAC is a general multi-block 3-D Euler/Navier-Stokes solver capable of operating in 
either Cartesian or cylindrical-polar coordinates, [9]. ADPAC employs an explicit four 
stage Runge-Kutta algorithm to solve the finite volume representation of the governing 
equations, and uses a variety of convergence acceleration techniques, such as multigrid and 
implicit residual smoothing. While the existing ADPAC code could solve axisymmetric 
problems, it did not incorporate the blockage, body forces, design mode logic, or loss 
modeling required for the different types of throughflow analyses required by TADS . 

4.5.1 Body Force Implementation 

At this point, some explanation of the various approaches to body forces is in order. Tbe 
idea of using body force terms to simulate the presence of bodies in a flowfield is not new, 
nor is it unique to TADS. Recently, two main types of body force models have been 
employed in CFD codes. 

A review of tlie literature shows that most previous authors add a force term to 
each momentum equation to account for the force exerted by the airfoil on the fluid. 
Frequently, these force terms are computed as pressure differences between the pressure 
and suction sides of an airfoil projected onto an element of area in each coordinate 
direction. Additionally, a blockage term is computed based on geometric quantities and is 
applied to the continuity equation. Any physical force could be modeled by these body 
force terms, simply by computing the magnitude and direction of the force. 

In 1985, J. Adamczyk of NASA Lewis proposed a method of modeling the presence 
of neighboring blade rows in turbomachinery calculations with what he termed an 
“average-passage” representation, [1]. In the Adamczyk scheme, the body force terms 
have a less physical interpretation. They are computed as the difference between an 
axisymmetric solution and the axisymmetric average of a 3-D solution. A source term is 
computed for each conserved quantity and for pressure. A blockage term is also computed 
to account for the presence of the body in the flow. The source terms are not computed as 
forces acting on the faces of the control volume, but are accumulated as flux differences at. 
each grid cell. In this procedure, the source terms automatically account for deviation and 
other phenomena which are not direct results of the pressure difference across the airfoil. 
However, this procedure requires a full 3-D solution to compute the body force terms. 

The present work follows a similar project in which researchers at NASA Lewis 
employed VI AD AC as a throughflow solver, [14]. VI AD AC and V STAGE are two codes 
which use the Adamczyk body force approach. In VI AD AC, the body forces are computed 
from stacked blade-to-blade solutions by the accumulation procedure outlined above. The 
original intent was to employ Adamczyk style body forces in an AD/ VI 6- based 
throughflow analysis. While ADPAC does not have the full average passage algorithm, the 
coding already existed to create and use Adamczyk-style body force files. It was hoped 
that simply verifying the existing code would provide a suitable throughflow analysis. 
After further study, it was concluded that the original blockage/body force term 
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implementation in the ADPAC code required some reformulation in order to be consistent 
with the design system strategy. 

The original blockage/body force implementation in the ADPAC code was based on 
the scheme developed for the VSTAGE and VI AD AC codes. This approach results in a 
coupled blockage/body force representation which did not permit accurate solutions for 
cases involving known blockage alone without a priori knowledge of the flowfield. 
Consequently, it was not possible to impose a geometric blockage (such as the global 
effects on channel flow due to an internal strut) in the axisymmetric flow unless the 
resulting axisymmetric flow is already known. This is contrary to the design system 
philosophy, and resulted in the reformulation of the blockage representation. 

A simple 2-D derivation of the revised A DP A C blockage term implementation is 
given below. Starting with the continuity equation in Cartesian coordinates modified for 
blockage represented by the term A: 


dpX 
~dt + 


dpuX 

dx 


dpvX 

dy 


-0 


Next, taking the x momentum equation in nonconservation form we have: 


(4.1) 


du dn Op du 

p m +pu te + te +pv di =0 


(4.2) 


If we multiply the continuity equation by u, and add to A times the x momentum 
equation, collect terms, and recast in conservation form, the result is 


dpuX d(pu 2 +p) A dpuvX dX 

dt dx + dy ^ dx 

Similarly, the y momentum equation becomes 

dpv X dpuvX d(fw 2 +p) X dX 

dt + dx + dy ^ dy 

Finally, the energy equation is 


(4.3) 


(4.4) 


dpeX du(pe + p) X dv{pe + p) X 

~ m + — to — + — % — =0 ,4 - 5 > 

It is clear that the addition of the blockage term results in a source term which must 
be added to the solution scheme in order to properly account for the effects of geometric 
blockage. 

The reformulated analysis utilizes a three-dimensional blade definition in the form 
of a mean camber surface (which must be accurately represented in the two-dimensional 
mesh) and a specified blockage (thickness) distribution over the bladed region. Actually, 
the 3-D definition is the mean stream surface, not the mean camber surface. In the 
absence of incidence and deviation, the two surfaces are identical, but explaining the body 
force formulation in terms of camber is often more intuitive. There are two possible means 
of calculating the body forces: a relaxation, iteratively-based scheme or a direct, 
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flux-based approach. Both techniques are based on the analytical technique described by 
Darnle, Dang, and Reddy [6]. 

In the relaxation, iteratively-based scheme, the body force utilized in the 
circumferential momentum equation is updated iteratively during the ADPAC time 
marching solution using a simple under relaxation procedure such that, at convergence, 
the resulting predicted relative flow stream surface is tangent to the local blade camber 
surface over the entire blade. The actual relaxation scheme formulation is given in the 
body force verification section ( 4.5.5). The corresponding axial and radial momentum 
equation body force terms and energy equation source term are also updated consistently 
based on the components of the local blade surface unit normal vector. This implies that 
the body forces thus represent the idealized pressure forces imparted by the airfoil on the 
mean flow. 

The direct, flux-based method calculates the body force required to satisfy the 0 
momentum equation for a Vg value that is tangent to the local camber surface angle. 
Consider the governing equation for the 0 momentum: 

— + Convective fluxes ( Conv ) = Diffusive fluxes + 
dt 

Source terms + Artificial dissipation ( Diss ) + Body forces (BF) 

For steady, inviscid, axisymmetric flows, the time derivative, the diffusive fluxes, 
and the source term (for the 0 momentum equation) are dropped leaving : 


Conv = Diss + BF 

At the desired flow tangency condition, the current 0 velocity ( Vg ) equals the 
desired value ( Vg *) along the blade mean camber line and the body force relation is 
satisfied. So, one can solve for the body force in the 0 momentum equation as : 

BF = Conv(Vg*) — Diss(Vg*) 

Where the notation Conv(F 0 *) means a flux calculated using Vg*. Just as in the 
relaxation method, the corresponding axial and radial momentum equation body force 
terms and energy equation source term are updated consistently based on the components 
of the local blade surface unit normal vector. 

When coding began on the direct method, the dissipation value that was subtracted 
from the body force relation was based on the current Vg. By inspection of the governing 
equation, one can see that calculating artificial dissipation fluxes based on Vg in the body 
force determination effectively negates the first artificial dissipation flux and thus the 
calculation becomes unstable. Thus, it is essential that Vg* be used used to calculate the 
dissipation term in the body force formulation. 

Another important coding change made during development of the direct method is 
that the body forces be updated every stage instead of just every iteration (like the 
relaxation scheme). Looking at the way the body force calculation is coded, it can be seen 
that the term Conv(IV) is essentially a convective flux like that in the governing 
equation. Stability dictates that convective fluxes be evaluated every stage; consequently, 
the convective flux based on Vg* must also be evaluated every stage in order to maintain 
stability. 
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The ADPAC multigrid and grid sequencing capabilities were modified to incorporate 
the direct and relaxation methods, providing a nearly threefold improvement in the 
convergence rate. 

In the early development of the body force throughflow capability in ADPAC, the 
direct, flux-based method was the first to be implemented. Unfortunately, it was found 
that the original coding was unstable in ADPAC . Only limited research into the causes of 
this instability was performed because the relaxation method was found to be sufficiently 
stable and robust. When testing began for the design mode routines in ADPAC , it was 
found that the relaxation technique used for updating the body forces reacts too slowly to 
the relatively rapid changes in blade shape. That is, there is a lag between the grid 6 
changes and the amount of time required to get converged body force values. So, in order 
for the design mode calculation to converge in a reasonable amount of time, faster 
convergence of the body forces was essential. This was the impetus for re-investigating the 
direct method. Changes (see above) were made that allowed a stable implementation of 
the direct method. 

Both body force updating methods are viable options for most analysis mode cases, 
but the direct method is faster and generally preferred. In the ADPAC input file, the user 
has control over which method is utilized for a given computation. The direct method has 
some difficulty with supersonic fan cases, but this is mainly because the body forces are 
updated so rapidly. These cases are discussed further in the body force verification section 
( 4.5.5). Because the relaxation method will work work for all analysis mode cases, it is 
default in ADPAC. 

The final ADPAC code retains the Adamczyk body force capability, but also offers 
the two reformulated approaches (direct and relaxation methods). Both the Adamczyk 
and the reformulated approaches use the same body force file format, but different 
meaning is attached to the variables. In addition to the source terms associated with the 
momentum and energy terms, there is also a pressure “body force” term in the Adamczyk 
approach which is unnecessary in the reformulated approach. The ADPA C User’s Manual, 
[8], explains the operation of these features. 

4.5.2 Throughflow Loss Model Implementation 

Because the ADPAC axisymmetric representation does not allow for circumferential 
gradients, there is no physical means of creating a blade boundary layer that will produce 
profile losses. Profile losses are particularly important for multistage applications where a 
proper total pressure profile going into the next blade row is essential for creating the 
correct operating point. By applying no-slip conditions on the hub and shroud, endwall 
boundary layer effects can be simulated, but they are 2-D (radial and axial directions) in 
nature and do not include the blade profile losses. Hence, a means of modeling blade total 
pressure losses through the passage is required. 

Much of the theoretical basis for the throughflow loss model was developed by the 
NYMA corporation through a subcontract off of NAS3-27394. NYMA also developed new 
routines and modified several ADPAC routines to allow for throughflow loss modeling in 
ADPAC. The remaining loss model work performed under NAS3-27394 involved writing 
routines to convert a total pressure loss coefficient definition into values suitable for the 
actual loss model source terms. The complete derivation of the loss model is given in 
Appendix A. 
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In the theoretical development in Appendix A, the loss formulation requires a 
relative total pressure value at the blade trailing edge. This value is supplied by the user 
through the total pressure loss coefficient file casename.tpl.#. The user has the ability to 
modify the loss coefficient definition to account for three dimensional secondary flow and 
endwall effects via the SDL OSS module described in section 4.6. 

During a computation with the loss model active, the following steps occur. 

1. During initialization, total pressure loss values and loss modeling triggers are read in. 

2. At a set interval, the loss source term values are updated. In order to get the proper 
values for the source terms, quantities along streamlines (determined from the 
current solution), not the grid nodes, are used. 

3. The loss source terms are added to the residual and the solution is updated. Note 
that, when a multigrid run is performed, the losses are only calculated on the fine 
grid and injected onto the coarse grids. 

It should also be noted that the source terms in the loss model definition conflict 
with the terms in t.he direct, flux-based method of updating body forces. Therefore, any 
loss model computations must use the relaxation method for updating body forces. 


4.5.3 Design Mode Implementation 

One of the primary requirements of task 10 is the implementation of a design, or “inverse” 
method for axisymmetric ADPAC. This design mode lets the user supply an aerodynamic 
requirement and an appropriate geometry is calculated. Thus, the design mode is the the 
compliment of the analysis mode where the geometry is known and the aerodynamic 
result is sought. 

In design mode calculations, the mean stream surface 0 angle, f(r,z), is the unknown 
quantity and the work or swirl distribution rVg*{r,z) is prescribed. The key equation that 
relates rVg* to f is developed from the flow-tangency requirement as given by Damle.Dang, 
and Reddy [6] : 


W • Vo = 0 


Vr 


o£ 

dr 


dj_ 

dz 


+ Vzzf = 


Vo* 


— U) 


Design mode calculation require the 6 grid coordinate to change. This change 
occurs either every iteration or at some chosen interval and requires a recalculation of the 
grid metrics and cell volumes. The body forces for the new grid are then recalculated as if 
it were an analysis mode run. The cycle is repeated until a converged mean camber 
surface shape is achieved. This procedure is shown in the flowchart in Figure - 4.6. In 
Figure 4.6, it is shown that the user still has the option of specifying either the direct or 
relaxation mode for body forces (even though the direct method was redeveloped 
specifically for the design mode). When to use the direct vs. the relaxation method in the 
design mode is discussed in the design mode validation section below. 

The actually procedure for solving for f(r,z) in the governing design mode equation 
is as follows. First, the derivatives of f(r,z) with respect to the radial and axial directions 
are calculated. Then, the value of f(r,z) is determined using a tridiagonal solver. The 
boundary condition for f(r,z) is: 
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Figure 4.6: Schematic of the flow of the design mode in ADPAC. 
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/(r, z) = 0.0 at i = ( ile + ite)f 2 

where ile and ite are leading and trailing edge grid indices respectively. From this 
essentially mid-chord position, the blade is "grown up- and down-stream to the leading 
and trailing edges based on the imposed rV e at every grid node location in the bladed 
region. Upstream of the leading edge, 0 grid values are set equal to leading edge 0 value. 
Likewise for the 0 grid values downstream of the trailing edge. In the design mode 
routines, instead of solving for the actual camber value f(r,z), an incremental change, A / 
is sought such that: 


yn+l = fn + adA f 

where n denotes the current camber update level and <v,i is a relaxation factor. By 
substituting f n+1 into the flow tangency relation, it can be recast in terms of A/. After 
solving the recast equation, A / can be scaled by a d to ensure that the change in the 
camber, f, is less abrupt thus enhancing the stability of the design mode. The relaxation 
factor a d , named FDESRLX in the ADPAC input file, is generally set between 0.05 and 
0.5. At the end of a design mode run in ADPAC, the converged mean stream surface is 
written to a PLOT3D file in SDB format called casename .mesh. new. As the name 
implies, this new mesh file is the same format as the starting axisymmetric mesh file. 

4.5.4 Verification of Blockage Model 

A sample application representing 2-D inviscid planar flow in a channel is presented in 
Figure 4.7. The channel has a linear variation in cross sectional area due to converging 
sidewalls. It follows that the blockage term A should also have a linear variation from inlet 
to exit in the duct. In this example, A was set to 1.0 at the duct inlet and 0.7 at the duct 
exit. Since the flow is inviscid and 2-D, the solution is essentially 1-D and can be 
determined based on area change and inlet Mach number alone. Due to the coupling of 
blockage and body forces in the VST AGE and VI AD AC codes, this type of flow cannot be 
accurately represented by specifying the geometric blockage alone. However, the predicted 
Mach number contours presented in Figure 4.8 based on the revised ADPAC formulation 
accurately reproduce the effects of the linear area variation with blockage specification 
only. 

4.5.5 Verification of Body Force Formulations 

Three test cases have been run to verify the body force terms: an annular twisting channel 
(S-duct), a compressor stator, and NASA Rotor 67. 

The S-duct, Figure 4.9, was chosen for its simplicity. It is an annular sector which 
has been twisted into a partial helix. A 49x9x9 grid was generated for an Euler 
calculation. The duct has constant width, so no blockage is encountered. The solution was 
run as a static geometry (no rotation), and the pressure body force term was omitted from 
the calculation. The body forces were computed using a full 3-D solution from the 
ADPAC-APES (Average Passage) code, and used in an axisymmetric run of ADPAC. The 
ADPAC solution converged easily. Figure 4.10 shows a comparison of the resulting 
ADPAC solution and the axisymmetric average of the 3-D solution. Clearly, the body 
force terms are working as hoped. 
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2-D Converging Channel 


Exit Blockage 
Factor = 0.7 



Figure 4.7: Simple channel flow with linear variation in cross sectional area results in a linear 
variation of the blockage term A. 
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0 78500 
0.30000 
0 *0500 



Figure 4.8: Predicted Mach number contours for simple channel flow with linear area variation 
using revised A DPAC formulation. 


S-Duct Geometry 


S-Duct is an annular channel with twisting. The inlet and exit are 
parallel to the machine axis so no body forces are present near the 
boundaries. The width is constant, so there is no blockage. 

Figure 4.9: S-Duct geometry is a partial helix constructed from an annular sector. 
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Body Force Implementation in ADPAC, S-Duct 



VALUtb 

1= 0.30C 
2= 0.31 C 
3= 0.32C 
4= 0.33C 
5= 0.34C 
6= 0.35C 
7= 0.36C 
8= 0.37C 


Absolute Mach Number 


9= 0.38C 
10= 0.3S 


11= 0.4C 


ADPAC Axisymmetric Solution with Body Forces 



VALUES 

1= 0.30C 
2= 0.31C 
3= 0.32C 
4= 0.33C 
5= 0.34C 
6= 0.35C 
7= 0.36C 
8= 0.37C 
9= 0.38C 
10= 0.3S 
11= 0.4C 


ADPAC-APES Axisymmetric Average of 3-D Solution 


Figure 4.10: The axisymmetric solution with body forces and the axisymmetric average of the 
full 3-D solution are in good agreement. 
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A simple stator test case was used to test out both the direct and relaxation 
methods of updating body forces. This stator has a circular arc meanline with 40 degrees 
turning and no radial variation of the blade camber so as to reduce debugging 
complexities. Figure 4.11 compares single grid convergence rates for the relaxation 
method and the direct method. It can easily be seen that the direct method converges 
considerably faster than the relaxation method. However, as mentioned above, the direct 
method updates body forces every stage. For a more accurate comparison, the relaxation 
method was coded to also update body forces every stage. The results in Figure 4.12 
show that the relaxation method is just as fast as the direct method. At first, this result 
suggests that there is little benefit to the direct method. However, in Figure 4.13, it can 
be seen that the direct method converges on the final massflow a little faster than the 
relaxation method. A better example of how the massflow converges faster for the direct 
method can also be seen for the NASA Rotor 67 test case in Figure 4.15. As will be 
discussed below, this ability is critical to the proper operation of the design mode m 
ADPAC. 

This test case highlights some of the benefits of a working direct body force method 
for TADS and ADPAC. First, the direct method is a much better theoretical basis for 
calculating body forces. Although the relaxation method works well and satisfies the flow 
tangency problem (i.e. minimizing the difference between the current and desired V e ), it is 
based more on physical reasoning than rigorous derivation of the governing equations. 
Second, the direct method removes the need for the ADPAC input variable FBFRLX (the 
under-relaxation factor in the relaxation method) which results in one less parameter that 
must be set or “tuned” by the end user. This reduces not only the complexity of a run, 
but it also improves the consistency of results amongst different cases. Finally and most 
importantly, the direct method allows for a stable design mode in ADPAC. It should be 
noted that the relaxation method will sometimes work in the design mode, but the 
magnitude of the relaxation factor and the frequency of the camber updating must be 
varied extensively from case to case (i.e. the user must experiment with values to obtain a 
stable solution). Therefore, it is more accurate to say that the direct method is a more 
consistent and reliable body force calculation method for the design mode. The benefits of 
the direct method over the relaxation method are discussed in more detail in section 4.o.6. 

NASA Rotor 67 provides a much more meaningful and difficult test of the body 
force formulations in ADPAC. An existing three-dimensional mesh was selected and 
altered to describe the airfoil in the mean stream surface/blockage format defined above. 
Computational results were collected from a 3-D solution based on the original (3-D) 
mesh, an axisymmetric solution based on the apparent body forces computed from the 
3-D solution, and the new throughflow analysis based on the mean camber surface mesh. 
It should be noted that the 3-D solution and the axisymmetric analysis with body forces 
computed from the 3-D solution result in, by default, identical axisymmetric flowfield 
representations, Therefore, only the axisymmetric solution is presented. 

The axisymmetric representation of the meslx used for this comparison is given in 
Figure 4.14. The grid density shown in Figure 4.14 is fairly typical of TADS throughflow 
computations. For the axisymmetric solution utilizing body forces derived from the 3-D 
solution, the mesh can have any variation in the circumferential direction as only the 
meridional portion of the grid is used during the numerical solution. However, for the 
throughflow analysis capability, the mesh must conform to the mean blade surface m the 
vicinity of the embedded blade row. The mesh surface is used to approximate the mean 
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Simple Stator Test Case 


Comparison of multigrid direct and relaxation methods 



Iteration Number 


Figure 4.11: Convergence history of the stator test case for an analysis mode calculation 
comparing the design and relaxation methods. Note that the relaxation method result shown 
here updates body forces every iteration while the direct method result updates body forces 
every Runge-Kutta stage. 
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Iog 10 (error) 


Simple Stator Test Case 

Comparison of direct and relaxation methods (multgrid runs) 



Figure 4.12: Convergence history of the stator test case for an analysis mode calculation 
comparing the design and relaxation methods for a multigrid run. Both the relaxation and 
direct methods update body forces every Runge-Kutta stage. 
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Massflow in/out (Ibs/s) 


Simple Stator Test Case 


Comparison of direct and relaxation methods (multgrid runs) 



Iteration Number 


Figure 4.13: Massflow convergence history of the stator test case for an analysis mode calcu- 
lation comparing the design and relaxation methods for a multigrid run. 
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Figure 4.14: Axisymmetric Mesh System for NASA Rotor 67 Test Case. 


blade surface to properly update the body forces for the momentum and energy equations. 
In the first set of calculations, the body forces for the throughflow analysis were updated 
using an ad hoc under relaxation procedure (i.e. the relaxation method) defined by: 

n 7 d l+x = B}1 + a(V e biade - V e actual ) (4.6) 

where B# and Bg +l represent the previous and updated circumferential momentum body 
forces, respectively, V blade is the apparent circumferential velocity required for flow 
tangency at the mean blade surface, V e actual is the actual circumferential velocity from the 
flow solution, and a is the under relaxation coefficient (0.5, in this case) used to update 
the body force. The body forces were updated at every iteration of the time marching 
solution. In the ADPAC input file, the keyword for the relaxation parameter in FBFRLX. 

The convergence history for the throughflow analysis using both the relaxation and 
direct methods is given in Figure 4.15. Solution convergence was naturally slowed by the 
constant manipulation of the body force terms, but convergence is ultimately achieved 
after approximately 700 iterations (500 for the relaxation method). Here, one can see 
that, just as in the simple stator test case, the relaxation method is as fast or faster than 
the direct method in terms of overall solution error. In terms of the convergence of 
quantities such as mass flow and pressure ratio, however, the direct method is shown to 
approach the final values much faster than the relaxation method. Figure 4.15 is also 
important because it shows how the direct method creates a rapid change in solution 
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quantities. Because the solution responds so quickly, the direct method is better at 
converging on the altered body forces resulting from a change in blade camber (in the 
design mode). From these convergence histories, one might argue that the best route for 
analysis mode calculations is to use the direct mode initially and then switching to the 
relaxation method to remove the high frequency oscillation from the solution. This is a 
viable option, but as a general rule, it is much easier to simply specify the direct method 
in the ADPAC GUI input panel and run the solution to full convergence. 

Figure 4.16 shows the predicted absolute total pressure contours using body forces 
from three different sources. The top plot shows the contours with body forces derived 
from the 3-D solution imposed on the axisymmetric solution. The middle plot shows the 
corresponding contours from the new throughflow analysis using the iterative body force 
calculation. The mean stream surface to which the flow was forced to be tangent was 
derived from the 3-D solution. Finally, the bottom plot shows the total pressure contours 
from the new throughflow analysis with the mean stream surface derived from the mean 
camber line of the airfoil and Carter’s deviation angle rule. In general, the predictions 
compare well qualitatively, but show some discrepancy quantitatively. The top plot shows 
a smeared shock near the trailing edge because this solution is equivalent to an 
axisymmetric average of a 3-D solution. Since the shock is not aligned with the 
circumferential direction, the average tends to diffuse the shock. The center and bottom 
plots show a sharp shock at the trailing edge because the shock is axisymmetric, a 
consequence of the axisymmetric analysis. The bottom plot also shows a total pressure 
gradient at the leading edge. This indicates that the mean camber line is not actually the 
mean stream surface. Between the various solutions, the mass flow agrees within 2% of 
the axisymmetric average from the 3-D solution. 

4.5.6 Design Mode Verification 

Two test cases for design mode validation are presented below. The first one, the AST 
Rotor 5 is a relatively simple case. The second case, Rotor 37, is significantly more 
difficult. In both cases, the direct method is used for body force calculations. In general, 
one should only use the relaxation method as an alternative when the direct method has 
difficulty converging the solution. 

The converged mean stream surface of the AST Rotor 5 is shown in Figure 4.17. 

For a first validation of the design mode in ADPAC , an rVg distribution from a converged 
analysis mode solution was used. The validation concept is that, at convergence, the 
resulting mean stream surface created by ADPAC should exactly match the axisymmetric 
mesh used in the analysis mode run. At convergence of the AST Rotor 5 case, the new 
mean stream surface grid differed from the analysis mode grid by a maximum of a 0.0005 
inches (for comparison, Rotor 5 tip clearance is 0.008 inches). 

As a second test of the design mode for the AST Rotor 5, a quarter sine wave rVg 
distribution was applied. Figure 4.18 compares Mach number contours between this 
design mode case and the analysis mode case. It can be seen that the solutions are 
radically different. The convergence for quarter sine wave case is very poor compared to 
the first validation run. Figure 4.19 shows that the convergence flattens even though 
other quantities in the solution are converging. This behavior is caused by an oscillation of 
the mean stream surface near a shock. When the mean stream surface shape is updated, it 
slightly changes the shock location. The change in shock location then alters the solution. 
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Total Pressure Ratio loglO(error) 



Figure 4.15: Convergence history for ADPAC based throughflow analysis applied to NASA 
Rotor 67. 
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NASA Rotor 67 Axisymmetric Throughflow Analysis 
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Figure 4.16: Predicted axisymmetric total pressure contours for NASA Rotor 67 based on 
ADPAC axisymmetric analysis with body forces from different sources. 
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Figure 4.17: AST Rotor 5 axisymmetric mesh generated by the ADPAC design 


mode. 
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Figure 4.18: Comparison of Mach number contours for the AST Rotor 5 case: (top) tVq 
distribution from converged analysis mode solution and (bottom) rVg from a quarter sine wave 
distribution. 


Then, the next mean stream surface shape update returns the shock to its original location 
and the process repeats itself. The conclusion here is that some imposed rVg distributions 
will yield solutions that are physically impossible or are very difficult to fully converge. 

NASA Rotor 37 is a very difficult test case for the design mode. With its high 
pressure ratio and large rotation speed, it’s a challenging case even for the analysis mode. 
Figure 4.20 shows the converged mean stream surface mesh created by the design mode 
throughfiow computation. 

Like the AST Rotor 5 validation case, design mode validation for Rotor 37 used a 
rVg distribution from a converged analysis mode solution. It can be seen in Figure 4.21 
that the analysis mode and design mode solutions are essentially identical. 

An attempt was made to set a quarter sine wave power distribution of rV$ across 
the blade, but the solution became unstable. One problem with trying to set a specific 
distribution is that Rotor 37 has a narrow operating range. Trying to enforce a r Vg 
distribution that causes the rotor to operate out of that range will either choke the flow or 
create a stall condition. Either way, the solution becomes unstable. A second problem is 
that the presence of strong shocks in the analysis mode solution creates unique flow angles 
which a smooth rVg distribution has difficulty matching. Because of these problems, it is 
recommended that, for high speed cases, the user take extra time to properly set a 
physically realistic rVg distribution and adjust boundary conditions (mainly exit static 
pressure) to account for a change in the operating point. 


46 


N ASA/CR-1 999-206603 



Iteration Number Iteration number 

Figure 4.19: Convergence history for the AST Rotor 5 with a quarter sine wave rVg distribution. 
4.5.7 Loss Model Verification 

Validation of the throughflow loss model was performed using the AST Stator 5 and NASA 
Rotor 37. The stator case is rather straightforward and the results compare well with a 
full 3-D ADPAC solution. The Rotor 37 case is much more complex and the TADS result 
does not match the full 3-D solution as well. However, the Rotor 37 case illustrates that 
the loss modeling can have a marked effect on the shock structure through the blade row. 

Figure 4.22 shows the total pressure loss coefficient profile that is being imposed at 
the trailing edge of the AST Rotor 5. This profile was taken from a streamline curvature 
solution. When running loss model cases, the actual loss model is turned on after the full 
multigrid start-up portion of the run has been completed (usually about 200-2o0 
iterations). This allows the solution massflow to stabilize before the loss source terms are 
applied (much like the delay in initiating the turbulence model in a 3-D ADPAC run). 

Figure 4.23 shows the trailing edge total pressure profiles for four separate 
solutions. It can be seen in the figure that the loss model effectively removes total 
pressure from the flow so as to model the full three dimensional flow more closely. It is 
important to note that the first two of the two dimensional solutions use a stream surface 
calculated from the three dimensional flow. The third two dimensional solution uses the 
blade’s mean camber line and Carter’s rule to define the mean stream surface. Comparing 
the shape of the profiles for the two inviscid solutions, it can be seen that just changing 
the inviscid mean stream surface can bring the 2-D solution closer to the fully 3-D 
solution. Thus, getting the inviscid portion of the solution correct can be just as 
important as correctly specifying the loss. This is the case because properly modeling a 
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Rotor 37 (design speed and back pressure) 





Level MACH 
10 1.401 

9 1.308 

8 1.216 

7 1.124 

6 1.031 

5 0.939 

4 0.846 

3 0.754 

2 0.662 

1 0.569 


Figure 4.21: NASA Rotor 37 case: analysis mode (top) and design mode (bottom) solutions 
show that Mach number contours at convergence are essentially identical. 
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Imposed Total Pressure Loss 


AST Stator 5, loss model validation 



Radius (in.) 

Figure 4.22: Plot of the total pressure loss coefficient for the AST Stator 5 case. Values were 
taken from a streamline curvature solution. 
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Trailing Edge Total Pressure Profiles 


AST Stator 5 Final Validation 



Figure 4.23: Plot of exit total pressure profiles for the AST Stator 5 showing (1) a 2-D ADPAC 
with loss model, (2) a 2-D d DPT <7 in viscid, (3) a 3-D ADPAC, and (4) a 2-D ADPAC \n\i\sad 
where the mean stream surface has been generated from only the blade camber and Carter s 
rule. Note that the first two 2-D cases used a mean stream surface derived from the full 3-D 
solution. 


three dimensional flowfield using an axisymmetric solution method requires accurate flow 
angles in conjunction with a correct total pressure drop. This is even more important in 
compressor fan cases where the nature of the transonic flowfield can actually make the 
inviscid portion of the flowfield more important than loss specification. Once losses are 
added (the first case shown in the legend), it can be seen that the resulting total pressure 
profile is the best match to the full 3-D total pressure profile. 


4.6 3DLOSS 

One of the traditional limitations to the (throughflow)-(blade-to-blade) (S1-S2) surface 
approach used in TADS is that it is difficult to merge the respective two dimensional 
effects into a three dimensional result. This is especially true in blade row corner regions 
where the 3-D boundary layer is much more complicated than a simple linear combination 
of the blade and endwall boundary layers. In these areas, the circumferentially uniform 
assumption of the throughflow calculation is false and the secondary flow field set up in 
the blade passage cannot be easily modeled. In response to this problem, a separate 
module named SDLOSS has been set up in an attempt account for three dimensional 
effects in the throughflow solution. 
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3DL0SS is a module that is accessible under the same panel as the ADPAC input 
panel. When run, it reads in the currently available total pressure loss files for every row. 
Then, the user has the option of running a spanwise mixing program to add three 
dimensional effects to total pressure loss and trailing edge deviation definitions. NOTE: 
3DLOSS has to have a current ADPAC axisymmetric grid and solution file to set up 
certain quantities in the spanwise mixing program. Therefore, running a 3D LOSS 
computation comes after a first pass at the axisymmetric solution with either no losses or 
a baseline (i.e. no endwall effects) total pressure loss coefficient file. 

The spanwise mixing program is called seclos. It was developed at Allison in an 
effort to model 3-D effects in the compressor design streamline curvature code. It is based 
on the spanwise mixing theory developed by Adkins and Smith, [2], 

4.7 Streamline Finder and Airfoil Slicer 

The blade- to- blade analysis is performed along streamlines in the meridional plane as 
found by the throughflow analysis. This requires that the meridional streamlines be 
located in the throughflow solution, and that the airfoil be sliced along these streamlines. 
TADS uses two separate programs to accomplish this purpose: RADSL and SLICER. 

4.7.1 RADSL 

RADSL locates the streamlines in the throughflow solution according to a distribution 
specified by the user in a GUI input panel. The user specified distribution is a normalized 
distribution which is applied at either the leading or trailing edge. The user selects 
whether the distribution is applied based on percent mass, percent span or percent area. 
The user selects the number of streamlines and the percentages where streamlines will be 
located. 

For example, if five equally spaced streamlines are to be placed at the leading edge 
on a percent area basis, the procedure is as follows. The normalized mass flow is 
computed from hub to shroud at each axial grid station in the throughflow solution. At 
the leading edge, the values of mass flow are found, corresponding to the five locations: 

0%, 25%, 50%, 75%, and 100% area. These streamlines are then traced through the entire 
domain. It should be noted that the chosen area distribution is applied only at the leading 
edge: elsewhere in the flowfield, the streamlines may not correspond to that particular 
area distribution. The percent span option functions similarly. If the percent mass option 
is chosen, then the distribution is held throughout the flowfield. 

There is one additional option: the user can find slices based purely on geometry, 
ignoring the flow solution. This option is triggered by selecting. “Everywhere” as the 
location at which to hold the specified distribution. In this release, the only available 
distribution function is percent area. This option is useful in cases where the throughflow 
solution is suspect, or where there is some reason to want the blade-to-blade solutions 
along a constant area slice instead of along a streamline. The GUI input panel defaults to 
five equal slices at constant percent mass, with the streamlines anchored at the leading 
edge. 

In all cases, the first and last streamlines are assigned to the hub and shroud as 
defined in the throughflow grid. User input which conflicts with this standard is ignored 
by RADSL. 
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Finally, RADSL interpolates the throughflow solution onto the streamlines. The 
output file is a PLOT3D flow file whose dimensions are the number of axial points in the 
throughflow grid, and the number of streamlines. This information may be used by the 
blade-to-blade analysis to set boundary conditions. Because the blade-to-blade analysis 
acquires its boundary conditions directly from the throughflow solution, the throughflow 
calculation is normally run in Euler mode. It is not clear how to set the total pressure, 
temperature and flow angle on the hub and shroud, when the velocities are zero on viscous 
surfaces. The current version of TADS expects the throughflow analysis to be run as an 
Euler calculation. 

4.7.2 SLICER 

SLICER uses the original airfoil description and the streamlines found by RADSL to find 
the airfoil cross-sections to be used in the blade-to-blade analysis. SLICER also reads in 
the aerodynamic information file and interpolates flow conditions from the radial profiles 
onto the streamlines at the leading and trailing edges. This information may be used 
instead of the PLOT3D file interpolated from the throughflow calculation to set boundary 
conditions in the blade-to-blade analysis. 

The process of slicing the airfoil along the streamlines involves repeatedly finding 
the intersection of two splines. Along each spanwise line in the airfoil definition, the 
intersection with each streamline is computed. The resulting airfoil description has the 
same number of points around the airfoil as the original definition. This airfoil description 
is used as the airfoil definition by the blade-to-blade grid generator. One limitation on the 
TADS system is imposed here: the spline along the span of the airfoil uses the radius as 
parameter. This means that centrifugal and radial devices cannot be handled by SLICER. 

4.8 GRAPE 

The blade-to-blade analysis uses the GRAPE code to generate a grid conforming to each 
axisymmetric surface defined by the meridional streamlines. GRAPE was originally 
written by Reese Sorenson at the NASA Ames Research Center as a 2-D Cartesian grid 
generator, [19, 20], The code was subsequently modified for cascades of airfoils by R. 
Chima of NASA Lewis Research Center, [5]. TADS uses GRAPE to generate C-type 
grids which are later used by RVCQ3D or B2BADPAC. A GUI input panel provides 
choices and defaults for the important input parameters. The user selects the grid size 
and adjusts various parameters to improve grid quality. 

GRAPE remains a 2-D Cartesian grid generator. However, a cylinder can be 
mapped directly into a plane by “unrolling.” This is equivalent to using the quantity 
Rcyl *8 in place of Y. where Rcyl is the radius of the cylinder. GRAPE can also be used 
for arbitrary surfaces of revolution by projecting the arbitrary surface onto a cylinder. 

The radius of the cylinder is set to the mean radius of the streamline. Further, the 
meridional distance is substituted for the X value in the grid so that the grid is along the 
streamline. RVCQ3D expects the grid in this format, and re-maps it to the proper radius 
internally. Since the grid for B2BADPAC is 3-D cartesian, the stacking process accounts 
for this meridional definition. 

A number of modifications were made to GRAPE for use in TADS. The output 
routine was rewritten to produce platform independent binary files by incorporating the 
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SDB library. Also, user experience led to changes in some of the GRAPE input 
parameters. These changes make it easier to specify a set of defaults which yield 
acceptable grids over a wide range of shapes. 

In the original code, some of the input parameters were inter-related. This was a 
source of user confusion, and proper handling of inter-related variables would require 
dynamic linkages between fields in the GUI. Since the dynamic linkages capability is not 
available in TADS , new parameters were introduced in the input routine, replacing similar 
parameters in the original code. The original parameters are then computed from the new 
parameters, leaving the internal workings of GRAPE basically unchanged. 

For example, GRA PE originally had parameters for the number of {joints around 
the leading edge and the spacing between grid points around the leading edge. To increase 
the point density around the leading edge, the user needed to decrease the spacing 
parameter, and also increase the number of points around the leading edge. To create 
suitable grids from default parameters, the revised code expects the user to specify the 
leading edge arc length and the number of points around the leading edge. The arc length 
of the leading edge region is computed internally by the GUI from the airfoil tangency 
points, which are specified in the casename . tdsaro file. The user specifies the number of 
points around the leading edge, and the spacing is computed by GRAPE. This change 
removes the inter-dependence between variables, and simplifies user input by computing a 
reasonable default value for the leading edge arc length. A similar approach was taken 
with the trailing edge parameters. 

The GRAPE code also requires the user to specify the grid index of the trailing 
edge. In a C-grid, there are two grid points which define this point, one on the lower 
surface and one on the upper surface of the airfoil. Originally, GRAPE required the user 
to specify both. Since the upper surface trailing edge index can be computed from the 
grid size and the lower surface trailing edge index, the upper surface parameter was 
eliminated from the input. The input routine computes the upper surface trailing edge 
index, and passes the value to the rest of the GRAPE code. 

In the GRAPE code, the leading edge point distribution is set by clustering points 
around a certain point on the airfoil surface. This point is specified as a fraction of the arc 
length around the airfoil, starting from the trailing edge. This parameter is named dsra, 
and has a default value of 0.5. The default value clearly inadequate for sharp airfoils with 
camber, because the cluster point will be located on the suction surface, rather than on 
the leading edge. However, it is difficult for the user to choose the proper value for dsra. 
The GRAPE input generation subroutine computes an appropriate value for this 
parameter from the airfoil geometry and the airfoil tangency points. The leading edge is 
taken to be at half the arc length between the leading edge tangency points. Figure 4.24 
shows a comparison between grids generated using the the default value of dsra and the 
value computed by the GUI for the hub section of NASA Rotor 67. 

Finally, the original GRAFF code expected to receive the location of the upstream 
and downstream grid boundaries, specified in inches. These quantities are difficult for the 
user to specify, and different values should be specified for each meridional streamline to 
achieve suitable grid quality. Some other blade-to-blade grid generators locate the 
boundaries as a fraction of the airfoil axial chord or the pitch between airfoils. These 
parameters are an improvement, but user intervention is still required. For a compressor 
fan. for example, specifying the boundaries as a constant fraction of axial chord results in 
grids with too much space upstream of the leading edge at theliub, and too little space 
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Improved Surface Point Distribution 

Figure 4.24: Comparison of airfoil surface point distributions in the GRAPE code. 
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upstream of the leading edge at the tip. Conversely, specifying the boundaries as a 
fraction of the airfoil pitch results in grids with too little space at the hub, and too much 
space at the tip. 

For the purposes of TADS , the boundaries are specified as a fraction of a distance. 
This distance is defined as the average of the axial chord and the airfoil pitch at each 
meridional streamline. In the cases tested, this has produced acceptable grids with 
minimal user effort. Two new parameters were introduced to GRAPE', xupfrc is the 
fractional distance of the upstream boundary, and xdnfrc is the fractional distance of the 
downstream boundary. Default values have been set for these parameters, but these may 
need to be adjusted depending on the shape of the airfoil (e.g. compressor blades normally 
require a smaller upstream fraction than turbine vanes). In GRAPE , the original 
parameters xleft and xright, are computed from the new parameters and passed to the rest 
of the code. 

4.9 GRAPE for B2BADPAC 

GRAPE for B2BADPAC is actually not a different module in TADS ; the source code for 
the GUI input panel is the same for both regular GRAPE and GRAPE for B2BADPAC. 

It. is actually a different way of running the GRAPE program so that full 3-D grids are 
generated for B2BADPAC. It was made into a separate option off of the main panel to 
avoid any confusion for the user. 

GRAPE for B2BADPAC module is run just like GRAPE module. The main 
difference between the two methods is that GRAPE for B2BADPAC attempts to limit the 
axial extent of the grid to the axial extent of the current throughflow block. See 
Section 4.11 for a more complete explanation. Hence, the GRAPE for B2BADPAC grids 
are generated in the same way as GRAPE grids, but they will generally be shorter 
(axially). After the user creates all of the blade-to-blade grids for a given row, GRAPE for 
B2BADPAC runs the program module b2badpac which reads in every slice grid and 
conveits them to a full 3-D mesh. If all of the blade-to-blade grids are not available (i.e 
have not, been generated), bSbadpac will exit. The grid generated by GRAPE for 
B2BADPAC is a left-handed, 3-D, whole, SDB binary cartesian mesh named 
casename .b2b.mesh. It is written to the proper casename .row.# directory in which the 
subsequent B2BADPAC run will be executed. 


4.10 RVCQ3D 

RVCQ3D is an Euler/Navier-Stokes analysis code capable of analyzing blade-to-blade flow 
in turbomachines using the quasi 3-D approach, [3, 4], The input to RVCQ3D is specified 
in a GUI panel. RVCQ3D uses C-type grids generated by the GRAPE code. The input 
grid is not along the streamline, but is along a cylinder with radius corresponding to the 
mean streamline radius as described above. RVCQ3D also reads a table of values 
describing the radius and stream tube height distribution along the streamline. 

The I/O routines in RVCQ3D were modified to utilize the SDB library in 
conformance with the TADS standard. Also, a change was made in the way that RVCQ3D 
sets boundary conditions at the upstream boundary in the following manner: RVCQ3D 
expects to receive aerodynamic information at the leading edge and it extrapolates to the 
upstream grid boundary. The procedure is similar to the way that ADPACBC 
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extrapolates data for the throughflow analysis. Since the blade- to-blade flow conditions 
are interpolated directly from the throughflow calculation, there is no need for RVCQ3D 
to perform an extrapolation. These modifications are limited and could be easily made to 
future releases of RVCQ3D. 

4.11 B2BADPAC 

When work began on multistage modifications for the TADS blade-to-blade modules, a 
straightforward extension of the GRAPE and RVCQ3D modules (from the single stage 
TADS ) was envisioned. However, several problems were encountered that prompted the 
use of a full 3-D solver with slip endwall boundary conditions. 

The first, and most difficult problem when using RVCQ3D in a multistage 
environment is related to upstream and downstream grid extents. Whether a single or 
multiple blade row TADS run is being performed, the blade-to-blade modules uses 
information from the throughflow calculation to set boundary conditions and quantities 
like stream tube thickness and radius that are necessary for the quasi-3D solution. In a 
single blade row run, the axial extents of the axisymmetric grid are usually one to two 
times the chord away from the blade leading and trailing edges. Thus, the blade-to-blade 
modules can interpolate boundary conditions and stream tube thickness from the RADSL 
output files. In an embedded blade row of a multistage calculation, the axial extent of the 
grid for a specific row is very short. Thus, the blade-to-blade modules must extrapolate 
quantities as shown in Figure 4.25. For a solver like RVCQ3D this extrapolation can lead 
to significant errors. Attempts were made to refine the extrapolation process, but they 
were too case dependent or required too much “tuning” by the user to give acceptable 
results. Shortening the axial extent of the blade-to-blade grid could alleviate this problem. 
However, this is not a viable option because the proximity of the inlet and exit boundary 
with the blade leading and trailing edges severely affects the solution quality. 

A second problem with RVCQ3D is that it has difficulty dealing with the higher 
pressure ratios in embedded blade rows. Lastly, since RVCQ3D has only limited numerics 
for convergence acceleration, code execution times for a large number of slices over a large 
number of blade rows can become prohibitive. Even with these problems (some of which 
are issues even in single stage calculations), RVCQ3D can still be used. However, it is 
much more efficient to perform a 3-D ADPAC run. This run uses a stack of the GRAPE 
C-grids (generated by the GRAPE for B2B ADPAC module) with inviscid hub and shroud 
endwalls. This method of calculation has the following benefits: 

1. ADPAC has an option for non-reflecting inlet and exit boundary conditions so that 
upstream and downstream blade row proximity is not a problem. 

2. Since the ADPAC run is a true 3-D calculation instead of a stack of quasi-three 
dimensional runs, the radial equilibrium and mass flow rate per streamline 
consistency is ensured. 

3. ADPAC tends to be a more robust code at higher pressure ratios. Because of its 
acceleration techniques, it is also a faster code than RVCQ3D. 

4. Although each blade row is run individually (at least during initial development and 
validation), it is possible to run a full multistage ADPAC calculation where each 
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upstream extrapolation region 


downstream extrapolation region 


Figure 4.25. Illustration of how using standard upstream and downstream extents for the 
blade-to-blade grid in a multistage environment creates large extrapolation regions 
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blade row is a cheap 3-D. That way, pressure effects between adjacent blade rows 
can be accounted for. RVCQ3D has no provision for multiple blade rows in a single 
computation. 

The only disadvantage to using the 3-D ADPAC calculation is that the user does 
not have the option of running a single slice (e.q. when tuning one radius or streamline). 
Because the designer usually wants the full hub-to-shroud stream surface though, this 
limitation seems minor. 

The generation of the input and boundary condition files for the 3-D ADPAC 
calculation is handled by the B2B ADPAC module. The 3-D ADPAC input file is very 
similar to the axisymmetric ADPAC input file. The only significant difference being the 
presence of viscous and turbulence model triggers. The boundary condition file is 
significantly different because it needs to account for a 3-D C-grid instead of a relatively 
simple 2-D axisymmetric mesh. Unlike for the axisymmetric ADPAC calculations, there is 
no boundary condition module (i.e. ADPACBC): all calculations and I/O for generating 
the input and boundary condition files for a B2BADPAC case are performed internal to 
the GUI. B2BADPAC was coded this way so that the user could examine/change 
boundary condition values interactively in a manner similar to RVCQ3D. 

B2B ADPAC runs are performed in the appropriate row subdirectory from the main 
running directory (casename .row.#). The naming convention is similar to other 
TADS files except a a “b2b” extension has been added to the base casename in order to 
avoid any possible confusion with the ADPAC throughflow files. Thus, the input and 
boundary condition data files are named casename. b2b.adpac. input and 
casename . b2b . boundata. 

4.12 Locating the Mean Stream Surface 

Once the blade-to-blade analysis is completed, the last task is to determine the mean 
hnb-to-tip stream surface between the airfoils. This task has two components: first the 
individual blade-to-blade solutions are restacked into a 3-D representation, then the 
axisymmetric average of the solution is computed, and the mean stream surface integrated 
from the averaged velocities. For B2B ADPAC solutions, the solution obviously does not 
need to be restacked, but averaging step must be completed. 

4.12.1 RESTACK 

RESTACK assembles the various blade-to-blade grids and solutions into PLOT3D X and 
Q files. This is a rather simple program: the only complication is in the conversion of data 
from the blade-to-blade representation to a true 3-D representation. If a B2BA DP A C run 
has been performed and no RVCQ3D solution file exists, RESTACK simply exits. 

The blade-to-blade solutions are not computed on a true (X, Y, Z) representation of 
the data: the two dimensions are ( M,Rx 6). These coordinates reflect what the flow 
actually “sees” along a streamline. Additionally, the velocities output by the throughflow 
analysis are (V m , Vg) The meridional coordinates and velocities must be converted to their 
3-D cylindrical polar equivalents, and then converted to Cartesian coordinates for output. 
The streamline file written by RADSL provides the data needed to transform meridional 
coordinates back to 3-D cylindrical polar coordinates. The meridional velocity is 
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converted to V x and V T by multiplying the meridional velocity by the unit vector tangent 
to the streamline. RESTACK is subject to alteration if other blade-to-blade analyses are 
incorporated into TADS. 

RESTACK is programmed to expect data in the form written by R.VCQ3D. In 
particular, RVCQ3D normalizes the aerodynamic quantities using a reference total 
temperature and pressure. For uniform upstream conditions, these reference quantities are 
normally set to 1.0, but radial profiles can be accounted for by setting different references 
on each streamline. TADS takes advantage of this capability. The hub streamline 
references are set to 1.0, and the other streamlines are set proportional to it according to 
the upstream profiles. No additional work is required to renormalize the flow on each slice 
to a consistent reference quantity when creating a 3-D file. The 3-D files created from 
RVCQ3D solutions are naturally self-consistent. Some other blade-to-blade solvers 
normalize the flow by setting the upstream total pressure and temperature to 1.0 
internally. These solutions would have to be renormalized to a consistent reference before 
restacking. 


4.12.2 MEANSL 

MEANSL finds the shape of the mean hub-to-tip stream surface between adjacent airfoils 
in either the RESTACK X and Q files or in the B2BADPAC grid and solution files. To 
perforin this calculation, the grid and flow data are converted to cylindrical polar 
coordinates. For B2BADPAC grid and solutions, the PLOT3D definitions are first 
converted to a right-handed coordinate system. Mass averaging is performed in the 9 
direction at axial locations chosen from the throughflow grid. The result is an 
axisymmetrically averaged flow solution on a 2-D grid: one dimension is the number of 
points in the axial direction, the other dimension is the number of meridional streamlines. 

The averaging procedure minimizes the dependency on the type or quality of the 
grid. MEANSL does the averaging as an accumulation of fluxes along a line, and not as an 
accumulation through 2-D faces. By formulating the average along a line, the dependence 
upon neighboring slices is removed. 

For each desired axial location along a streamline, two sweeps of the grid are 
performed: the first finds all of the intersections with the grid lines which wrap around the 
airfoil (contours), and the the second finds all of the intersections with the lines emanating 
from the airfoil (normals). The intersections are then sorted by 9 , in the passage between 
adjacent airfoils. The axisymmetric averages are then computed by accumulating the 
fluxes along the sorted line. 

This averaging procedure has a number of advantages. The procedure does not 
expect any particular grid topology, simplifying the job of adding different blade-to-blade 
analyses. The accumulated fluxes are comprised of as much data as possible because every 
intersection between the grid and the line of interest is used. Therefore, boundary layers 
or other flow features are resolved as well in the accumulation of fluxes as they are in the 
solution. This would be of particular benefit for blade-to-blade analyses with adaptive 
gridding. 

The axisymmetric average data is used to determine the shape of the mean stream 
surface between the airfoils. The averaged velocities are, by definition, tangent to the 
mean stream surface. An integration is performed along each meridional streamline to 
find the shape of the mean blade-to-blade stream surface from the averaged velocities. 


60 


NASA/CR-1 999-206603 



The tangent to the mean stream surface is formed as the angle between the 
circumferential velocity and the meridional velocity. By integrating the angle with respect 
to the meridional distance along the streamline, a mean stream surface is determined. The 
output of MEANSL is a PL0T3D X file containing an axisymmetric grid, warped into the 
shape of the mean stream surface. This shape would be interpolated onto the full 
throughflow grid by BODYF to apply this stream surface shape in the throughflow 
analysis. 
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Chapter 5 

Development of GUI 


The Graphical User Interface (GUI) for the TADS system controls the operation of the 
program modules. It organizes the work flow into logical pieces, and provides a simple way 
to select or modify program input parameters. The design mode pre-processor and the 
TADS post processor are also GUI items, but they are standalone items which can be run 
outside of the TADS GUI. 

5.1 Panel Overview 

The GUI consists of a number of interactive panels with push buttons, pull-down menus, 
text fields, etc. These panels allow the user to select which programs to execute, create 
input sets for the chosen modules, and configure remote hosts on which modules can be 
executed. The GUI is written using the Motif widget library under X-Windows. Motif 
and X-windows are highly portable, having become a de-facto standard among 
workstation and supercomputer vendors. 

5.1.1 Main Panel 

A main panel controls the operation of all other panels within the GUI and all program 
module execution, Figure 5.1. There are three groups of buttons on the main panel, the 
group on the left is the “program mode selector” , the buttons on the right are the 
“component group controls”, and the buttons on the bottom are the action buttons. 

The program mode selector determines the appearance of the main panel, and the 
behavior of the component group controls. The component group controls allow the user 
to make choices regarding each functional task in the analysis. The action buttons allow 
the user to define remote hosts, open a UNIX shell, or exit the GUI. 

There are five modes of operation available in the program mode selector. The 
selected mode determines how the GUI will respond when program modules are selected. 
The first mode, labeled “Edit Programs,” causes the component modules to change 
appearance from push buttons to pull-down menus, Figure 5.2. The pull-down menus 
allow the user to select a program module to perform each task (e.g. TIGGERC or Batch 
TIGGERC can be chosen for the axisymmetric grid generator). At present, most 
component modules have only one working choice, but the capability was added so that 
users could easily incorporate their favorite grid generators and flow solvers into the 
TADS system. The program modes labeled “Edit Data, 1 “Edit/Run, and Run cause 
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Figure 5.1: The Main panel of the GUI controls the complete analysis. The “Edit/Run" mode 
is shown here. 
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Figure 5.2: In the “Edit Programs” mode, the user selects program modules from a pull-down 
menu for each component of the analysis. 

the component modules to appear as either push buttons or toggle buttons. These modes 
control input creation and program execution of the component modules. In the 
“Edit/Run” and “Run” modes, a small green button labeled “Run” is enabled at the 
bottom of the component group controls as seen in Figure 5.1. The user selects which 
modules are to be run using toggle buttons to the left of each component. When all of the 
desired modules have been selected, the user selects the “Run ’ button to start the 
execution process. In the “Edit/Run” mode, the input panel for each selected module is 
brought up, starting at the top of the component groups and working down. After the 
user finishes with the input panel, the program module is run. The program modules are 
run sequentially until all selected modules have been completed. In the “Run” mode, no 
input panels are brought up. The selected modules are simply run starting at the top and 
continuing down the component group. 

In the “Edit Data” mode, the user selects push buttons which bring up the 
appropriate input panels, Figure 5.3. The input data is created and saved foi that module 
only, and no execution is performed. The user may select these panels in any order. One 
strategy for running the GUI is to use the “Edit ’ mode to define all of the input 
parameters needed for each program module, and then the “Run” mode is used to execute 
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Figure 5.3: Input data panels for the program modules can be accessed from the main panel 
in Edit/Data mode. 


the entire analysis. This keeps the user from having to wait for programs to finish before 
setting up the next program module. 

Another strategy is to use the “Edit/Run” mode to perform the analysis piecemeal. 
It is frequently convenient to select only the modules associated with the tliroughflow 
analysis to be sure that an acceptable solution has been obtained before attempting to run 
the airfoil sheer and blade-to-blade modules. The remaining modules can be executed as a 
second step. The advantage of this strategy is that later modules will not have to be rerun 
because of errors in an early module. Because of its flexibility, the “Edit /Run” mode is 
the most common approach to controlling an analysis. 

The final mode of operation in the main panel is labeled “Edit Machines.” This 
panel is shown in Figure 5.4. This mode allows the user to select which host is to perform 
the calculations for each program module. It is often advantageous to run the longer 
running portions of the analysis (e.g. the tliroughflow and blade-to-blade flow solvers) on 
a remote machine to take advantage of faster processors. This option is only functional if 
hosts other than the local machine have been configured in the remote host setup panel. 

At present, all slices in the blade-to-blade analysis must be run on the same host. 
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Figure 5.4: In the "Edit Machines” mode, the user selects a host processor for each program 
module. 
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Type: 


■#> Silicon Graphics 
O IBM 

O SGI Power Challenge 
O Other 


Environment Variable NASATDSDIR: 


| /scrl/iedat/NASA_TDS 
Working Directory Path: 


j /scr1/iedat/NASA_TDS/example$/TRY 


Figure 5.5: Program modules can be run on remote hosts configured using the Setup Panel. 


In addition to the main panel, a status panel is created whenever the GUI is 
executed. This panel gives information about the function of certain buttons, and 
indicates when a program module is being executed. It displays the name of the module, 
the host on which it is being run, and the pathname to the current working directory. 
This panel is for display only, and no user input is accepted in this panel. 


5.1.2 Remote Host Setup Panel 

The action button labeled “Setup” opens a display panel for defining remote hosts, 

Figure 5.5. All modules within the GUI can be executed either on the local host or on a 
remote host. The remote hosts must be configured so that the GUI can call the 
appropriate executables in the appropriate directories. The text block labeled “Hosts” 
lists the available hosts for execution. Only hosts on this list can be accessed for remote 
execution. The radio button group labeled “Type” specifies the vendor and machine type 
for each host. At. present, the panel has choices for Silicon Graphics and IBM RS/6000 
workstations. There are two possible SGI choices to differentiate between the SGI R4000 
chip and the R8000/R 10000 chipsets. The SGI Power Challenge selection uses executables 
which have been optimized to run on the R8000/R10000 chipsets. The text boxes at the 
bottom right of the panel specify the paths to the executables and to the working 
directory for the highlighted host. Each host can have different paths for both executables 
and working directories. This was designed to work with NFS mounted file systems which 
may have different pathnames to the same directories on different machines. The buttons 
at the bottom of the screen are action buttons which handle the saving and restoring of 
data, and allow the user to return to the main panel. A similar set of buttons exists in all 
input panels. The specific function of these buttons is discussed in Section 5.1.5. 
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Figure 5.6: The ADPAC input panel is an example of a simple input panel. 


5.1.3 Input Panels 

Most of the panels in the GUI are for creating input files for program modules. These 
input panels are similar in form and function, but some control multiple executions of the 
same program. Specifically, the panels associated with the blade- to-b lade analysis have 
additional features to deal with the fact that the program modules they control must be 
run once per streamline. These panels, called “slice-dependent ’ panels, are discussed in 
the next section. Examples of simple input panels are the TIGGC3D input panel and the 
ADPAC input panel, shown in Figure 5.6. The GRAPE and RVCQ3D input panels are 
slice-dependent panels. 

An input panel is essentially a container widget which holds other widgets 
corresponding to input variables in the program modules. Action buttons at the bottom of 
the panel control the saving of data and closing the panel. The control widgets are most 
often edit-able text fields, but can also be pull-down menus or toggle buttons. The control 
widgets are laid out in a row-column matrix with labels indicating their significance. 

Each input parameter has a separate controlling widget and label. Provision has 
been made to include a brief description of the highlighted input parameter on the screen 
as a reminder of its function. This reminder appears at. the top of the screen, adjacent to 
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the casename, and it changes with the input focus. This provision has not been fully 
implemented, but it is available in all input panels. All that is required is to add a text 
string for each variable in the GUI panel code. 

In the case of text fields, provision has also been made for input data checking for 
valid types and ranges. For example, an integer field will not accept fractional entries or 
character data. Also, the entered value must lie within an acceptable range, or the entry is 
not accepted (an error dialog widget will appear and indicate the proper data range). The 
acceptable data range and the defaults for all inputs are hard-coded into the source code 
for each input panel. The values typed into a text field are checked and accepted 
whenever the input focus changes. 

Focus changes when the enter key, tab key or mouse input is received by the GUI. 
This does not mean that the data has been saved permanently, or that it will be written 
to an input file, but merely that it is part of the current data set. Data saving and input 
file creation are accomplished through the action buttons. The point here is that the user 
can create and view a complete input set before committing to the changes. Provision is 
made to abandon all changes made since the last save through the action buttons. 

For variables with few options, pull-down menus and toggle buttons are employed. 
Toggle buttons are used in cases where the variable is either “yes” or “no,” “true” or 
“false.” Examples of this are triggers to generate a restart file, run viscous or inviscid, etc. 
The actual input variable may be an integer, but in each case, the input parameter 
controls an either/or choice. 

Variables with limited options are well suited to the pull-down menu. Pull down 
menus display the values of the available choices and a brief description of each choice. 

For example, the RVCQ3D input panel uses a pull-down menu to select the type of 
upstream boundary condition to be employed: subsonic flow holding inlet flow angle, 
supersonic flow, or subsonic flow holding circumferential velocity component. The 
description fields are especially helpful for variables which are rarely changed. 

Each input panel has a default dataset which is part of the initialization code. Some 
of the input panels have database files associated with them which keep track of previous 
user choices for a particular case. Other input panels use the input files created in 
previous runs of the same case. When available, data from these files are loaded into the 
input panel and form the initial data set. The idea is to minimize user input requirements 
by using the results of a previous run as the initial data set for the current run. 

Some input variables in one program must be consistent with input to other 
programs. For example, the grid size for the blade-to-blade solver is set when generating 
the blade-to-blade grid. Therefore, the user is prevented from changing the grid size in the 
blade-to-blade solver input panel: the value input to the grid generator panel is displayed, 
but can’t be edited. When a text box can be edited, the background of the box is white. 
When a text box is for display only, the background is the same as the background color 
of the container widget. 

Where possible, the input parameters are grouped as they appear in the program 
module documentation, or in sample batch input files. This may be a drawback for 
inexperienced users, especially in cases where the organization of the input files is poorly 
conceived. For the user who is used to running the programs outside the GUI, it is 
beneficial to group them in the customary order. 
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5.1.4 Slice-Dependent Panels 


There are a number of additional features and complications associated with 
slice-dependent panels. Figure 5.7 is an example of a slice-dependent panel. The most 
important aspect of slice-dependent panels is understanding how data is used and saved 
between slices. In simple input panels, there is no ambiguity; values are set and used in the 
normal manner. However, in dealing with slice-dependent panels, there are some variables 
which are the same for all slices, and some which vary from slice to slice. For example, the 
number of blades on the wheel is a constant along the span of an airfoil, but the axial 
position of the inflow boundary may vary between meridional slices. It is important to 
know when a variable is set for all slices, and when it is set for only the current slice. 

In slice-dependent panels, there is an additional widget in the upper right-hand 
corner which indicates which slice is being edited. This widget is a pull-down menu with 
an entry for each slice plus an entry for “All Slices.” When “All Slices’ is selected, the 
variables which are changed in the panel are set as constants for all slices. When data is 
saved, it is saved for all slices, any individual slice modifications are lost. A warning panel 
is displayed to alert the user, and a confirmation is required before data is over-stored. In 
any event, only edit-able variables are propagated for all slices; parameters which are not 
edit-able are set internally for each slice. 

Variables which are set individually for each slice are not edit-able in the All 
Slices” view. When an individual slice is selected, only the variables which can vary 
among the slices are edit-able. When data is saved from the individual slice view, only the 
data for the current slice is affected. There are some variables which are frequently 
constant for all slices, but are sometimes slice-dependent. There is a provision for treating 
a single variable as either constant or variable among the slices, but most of these have 
been converted to slice-dependent, variables to remove the confusion surrounding their use. 

The slice-dependent, panels make use of a relational database which is maintained 
for each slice dependent panel. The database files are random access binary files, 
containing the values of all parameters for all slices. The database files follow the naming 
convention casename.program_name.db (e.g. rotor67.grape.db). When data is saved, it is 
written to the database file, and when data is restored, it is re-read from the database file. 
When a slice-dependent panel is exited, new input files for the program module are 
created for each slice. Simple input panels do not employ a database, but rather work 
directly with existing input files, when available. 

The recommended procedure for setting data in slice-dependent panels is to set the 
values for “All Slices” first. After saving the “All Slices” data, then select the individual 
slice panels which require modification. Save each of these panels and return to the main 
panel. 

As before, not all parameters can be set by the user. Some are computed from 
known data (such as the number of blades and the airfoil pitch), and some are set in other 
panels and may not be modified (such as grid sizes, etc). 

Another feature is provided in slice- dependent panels which is not available on 
simple panels. When viewing the input panel under the “Edit Data mode selec ted in the 
main panel, an additional action button is displayed. This button, labeled “Run,” allows 
the user to execute the program module for a single slice instead of for all slices. This is 
particularly useful when the user is unsure of the parameters chosen for the blade- to-blade 
grid generator or flow solver. Instead of waiting for all slices to run before discovering an 
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Table 5.1: Action buttons on standardized input panels control file creation, modification and 


UM. 

Save 

Overstore current panel data to a file if changes have been 
made. If no changes have been made, then no action is taken. 

Restore 

Restore current panel data from a file. Any changes not saved 
prior to a restore are lost. This action button is only active 
if the input file exists (from a previous save). 

Default 

Reset current panel data to default values. These defaults are 
setup specifically for TADS. This means they are not neces- 
sarily the same as the defaults stated in the formal documen- 
tation of the individual component modules. Any changes 
not saved prior to a default are lost. 

Done 

Save current data and then exit current panel. In some in- 
stances, this action button will force the execution of sec- 
ondary component programs such as preprocessors. Also, a 
message will appear in the message panel indicating any pro- 
grams being executed. 

Cancel 

Exit current panel without saving current changes. If a save 
has been done prior to cancel secondary programs will be ex- 
ecuted (if appropriate) as described above for done If changes 
have been made to the data without a save being done, the 
user will be so informed and given the option to return to the 
current panel. 


input error, the user can execute a single slice ami check the results before executing the 
other slices. This is also useful, for checking the sensitivity of an analysis to a particular 
parameter (such as incidence angle). A single slice can be run repeatedly without running 
any other slices. To avoid confusion, the “Run” button is de-activated when “All Slices” is 
selected from the pull-down menu. The button is activated only when the user is viewing 
the data for a single slice. 

5.1.5 Action Buttons 

All of the input panels in TADS have a row of action buttons located across the bottom of 
the panel. Generally, these action buttons control file creation and modification. Some 
buttons also initiate program execution. Generally, these buttons behave as described in 
Table 5.1. The few exceptions are documented in the User’s Manual. 

5.2 Programming Philosophy 

The programming philosophy used in creating a GUI can make the difference between an 
intuitive, easily maintained interface, and a confusing interface built on tangled code. 
Recognizing the importance of standardizing the look and feel, the structure of routines, 
and the exchange of data between programs, the TADS system follows an object-oriented 
approach. 

Conceptually, an object oriented approach means that the program modules aie 
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designed around the function they perform instead of the data on which they operate. 
Most codes are built around the data. This means that each routine is specific for the job 
it performs. In this model, it is often difficult to re-use code because the data structure is 
embedded in the routine. A slightly different problem requires all new code. Under the 
object-oriented approach, the routines are written around the function they perform. 

Code re-use is planned from the start. The GUI is programmed in C, which is not an 
object-oriented language, but object oriented philosophy was adopted where possible. 

An object oriented approach was used in generating the panels: eacli panel can be 
considered to be an instance of a model. That is, each panel is patterned after a model 
with changes only to the data to suit a particular use. The code interprets the data 
structure and creates appropriate objects for each input parameter. 

To clarify the idea behind object-oriented programming, consider the following 
example. Suppose that two input panels are to be created. The first panel requires a 
pull-down menu for the first input item, and text fields for all others. The second panel 
requires a pull-down menu for the second and fourth items and text fields for all others. 
Traditional programming would write two separate routines to handle these cases. While 
much of the two routines would be common to both, custom coding would be used to 
handle the special cases. The traditional approach is data-oriented programming: routines 
are written specifically for the data that they handle. In the object-oriented approach, 
only one routine would be written, capable of handling each case. Each input, item has 
associated data which indicates the desired type of widget. The code simply knows that 
each input item will require an object on the display panel. The type of object to be used 
is interpreted for each parameter. With the object oriented approach, the data structure 
is larger, but there is very little redundant code. A further benefit is realized in the 
object-oriented approach in that changes to the objects are automatically effective for all 
panels, minimizing code maintenance. 

5.2.1 Panels as Objects 

There are four model panels in TADS : the main panel, input panel, slice-dependent input 
panel, and the remote host setup panel. Eacli model panel has flexible data structures 
which are used in each panel of its type. A new instance of the structure is created for 
each panel, and the particular data is loaded into the structures, but the function and 
nature of each structure is the same in all panels. The data structures are comprised of 
many records, one for each input parameter on the display. Included in the data structure 
is the parameter name, the value, the valid limits for the values, the type of widget to be 
displayed, and some information about initialization. 

5.2.2 X-Windows/Motif Widget Implementation 

The GUI is programmed with the Motif widget library running under X-Windows. As is 
customary with X-Windows/Motif applications, a resource file controls the colors, fonts, 
borders, and other aesthetic features of the individual windows and widgets. One 
weakness of the X-Windows system is that there is no standard way to refer to font 
names, and no guarantee that the fonts used by an application exist on a particular 
machine. In particular, SGI and IBM differ on the proper names for fonts. A separate 
resource file is provided for SGI and IBM implementations of the GUI. If other types of 
workstations are to be used, there may be some modification required to achieve a 
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working set of fonts. One point of confusion is when the GUI is run on a remote machine 
with the panels displayed on a local machine. In X-Windows, the fonts are resolved on the 
local machine. That is, if the user is sitting at an SGI workstation, the SGI resource file 
should be used, even if the GUI is run as a remote process on an IBM workstation. 

Most of the objects which appear in the GUI panels are conglomerations of Motif 
widgets. There are many instances where widgets were combined or customized, but the 
following four examples are most often used. The ability to enable or pi event editing of a 
parameter was required to prevent users from specifying contradictory input. Part of the 
data structure determines the conditions under which a particular parameter is edit-able. 

A special widget was made which contains both a text entry field and a label. The ability 
to group widgets was required in the airfoil sheer input panel. Figure 5.8. Pulldown menus 
were customized to cause the background color to change when the widget is enabled or 
disabled. In each case, the underlying routines for the screen objects are pure Motif 
widgets. Following the object oriented philosophy, new objects were created from existing 
objects to minimize coding and maximize the clarity of the main routines. 

5.2.3 Scope of Data 

A common issue when coupling codes into an integrated system is that of the scope of 
data. The basic question is: “If a parameter is changed in one routine, do all other 
routines receive the changes?” Most parameters are strictly local. The advantage of local 
parameters is that there are no unintended side-effects. Often, two programs will have a 
variable of the same name with different meanings. Local variables keep the modules 
isolated. 

Certain parameters have been identified within the GUI which have global scope. 
These parameters are available to all routines within the GUI. Among them are the 
number of airfoils, grid sizes, reference total pressure and temperature, and the wheel 
speed. The global parameters are listed in the routine globals.c. There are other 
parameters which are shared between routines, but are not global in scope. Most data 
sharing is accomplished through I/O in shared files. An example of this sharing is the 
axisymmetric grid. Many routines read the grid as input, and two routines write out the 
file. This type of data sharing is not truly global in that only routines which read the file 
receive updates to the data. 

This means that it is a simple matter to generate a new panel of a given type. The 
changes consist of filling the data structure with the input parameters for the particular 
application, and adding a new stanza to some conditional blocks to show the new choice 
on parent menus. New stanzas must be added to the call-back block to show how the 
application is executed, and some parameter statements need to be added to a header file. 
Adding a new panel can be accomplished in about two hours if a suitable model exists. 

5.3 Pre-Design and Post Processor Modules 

There are two program modules in TADS that, since they are so graphically intensive and 
so conceptually different than the main TADS modules, they are described in this chapter 
on GUI development. The design mode pre-processor (referred to as PREDESIGN) is 
used to set up data for a TADS design mode run. The. TADS post processor (referred to 
as POST) is used to view data from the various TADS program modules. These modules 
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Figure 5.8: The Sheer panel of the GUI enables the user to control the location of the meridional 
streamlines for blade-to-blade analysis. Radio buttons are grouped and interconnected to insure 
consistent input. 
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are accessed from the TADS main panel. However, they are true stand-alone programs 
that can be run outside of TADS if required. 

5.3.1 General Features of POST and PREDESIGN 

Both modules consist of a main window with multiple pop-up windows for viewing various 
types of data. Every window consists of a main menu bar, an optional toolbar area, and a 
plotting area. The main menu area has pulldown menus for performing different functions. 
The toolbar area has pushbuttons that have appropriate pixel maps pasted on them to 
denote their functions. The plotting area contains plot(s) for viewing a given set of data. 
The different types of data and plots for the various windows are described in the later 
sections of this chapter. 

In the TADS GUI, many parameters (e.g. the maximum number of blade rows or 
maximum number of remote machines) are hard coded and the user must recompile every 
time they are changed. In many cases, this had to be done because of TADS ’s interfaces 
with Fortran code that does not have a true dynamic memory allocation capability. In 
POST and PREDESIGN , dynamic memory allocation is used whenever possible. 

Although this can result in a more complex source code, the resulting module is capable of 
handling a wider range of problem sizes. 

PREDESIGN and POST use a X-Windows/Motif plotting widget called SciPlot 
which is available as freeware [13]. The proper GNU copyright information for freeware 
and shareware is included wherever SciPlot source code is being utilized. In its publically 
available form, the SciPlot widget is only capable of static display of X-Y line data. For 
the Pre-Design Module, the widget has been modified to allow click-and-drag type editing 
of the displayed data. This capability simplifies data modification in the Pre-Design 
modules. PREDESIGN and POST share many similar plotting and GUI functions 
(besides the SciPlot widget). Just as there is a guilib (GUI library) directory in the 
TADS main directory, a plotlib directory contains source code for shared routines. 

Both modules have certain convenience features like hardcopy output, zooming, 
changing axes titles, etc. These features are explained in greater detail in the /TADS 
User’s Manual. 

Some programming methodologies used in PREDESIGN and POST were taken 
from the shareware plotting package called ACE/gr [22]. Where source code is similar 
ACE/gr, the proper GNU copyright information is included. 

5.4 PREDESIGN 

During the development of the design mode for TADS , it was recognized that user would 
have to manage a substantial amount of data that would be difficult (A) to create outside 
of TADS and (B) to manipulate without a plotting interface that had a click-and-drag 
editing capability. These requirements were the impetus for creating the Design Mode 
Pre-processor Module ( PREDESIGN ). 

When invoked, PREDESIGN searches the current directory for the 
TADS aerodynamic data and flowpatli files. From these files, it generates a plot of the 
flowpath and blade leading and trailing edge geometry. This plot appears in the main 
window (shown in Figure 5.9) and the user has the option of moving eithei the wall or 
blade geometry points using the click-and-drag editing discussed below. 
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Figure 5.9: Main panel in PREDESIGN showing the meridional projection of the axisymmetric 
throughflow grid, row control bars and convenience pushbuttons. 

5.4.1 Click and Drag Editing 

PREDESIGN has a built in editing capability for modifying points in a chosen plot. Under 
the “Edit 7 ’ pull-down menu. The user has the option of adding, deleting, or moving points 
on a chosen plot. When the user quits the editing mode, the changes on the modified plot 
are saved. Details on using the editing capability are discussed in the User’s Manual. 

As mentioned above, the original SciPlot widget in it’s publicly available form, does 
not have a point editing capability. When work began on the PREDESIGN module, a 
series of slider bars for manipulating plot data was envisioned. It was quickly realized, 
however, that such an interface would be far too cumbersome for general use. Hence, the 
original widget source code was modified to incorporate the click-and-drag capability. As 
per the GNU license agreement for publicly available software and source code, these 
modifications have been made available to the original SciPlot author. 

5.4.2 rYg values 

In PREDESIGN there are two pop-up panels that display rVg quantities: one for the 
leading and trailing edge rVg profiles, and another for showing the axial distribution of 
vVq from the leading to trailing edge. 

When In PREDESIGN is invoked, it searches the current directory for a 
casename .rvtdesign file. This file contains the data required for these two plots windows. 
If this file does not exist, default values are generated using the aerodynamic data file. 

The leading and trailing edge rVg profiles can be edited using the click-and-drag 
editing capability. The axial distributions are generally edited by changing the exponent 
in the quarter sine wave definition (see the BODYF section for an explanation of axial 
distributions). 

For each window, the user has the option of writing the casename .rvtdesign under 
the ' b Dat,a” pull-down menu. Note that the user must cause the writing of this file; 
PREDESIGN will not do it automatically upon exiting. 
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5.4.3 Blade Shape Calculation 

In a design inode run, because a blade shape does not always exist a priori , some means 
must exist to generate one. The blade shape is required for two main reasons: (1) to give 
the bodyf routine a shape from which to determine an initial guess for the mean stream 
surface to be used in the throughflow solver and (2) to establish the metal blockage 
written to the casename . bf . # file. 

When PREDESIGN is invoked, it searches the casename. rvtdesign file for various 
triggers associated with blade design. Currently, it reads in triggers for blade profile shape 
(DCA, MCA, etc.), leading and trailing edge metal radii sizes, true blade chord, and blade 
metal angles. PREDESIGN will use default values whenever it needs blade design 
information not present in the casename .rvtdesign file. 

The blade profile shapes are generated using the several routines adapted from a 
compressor streamline curvature code and blading package (Allison’s in-house code called 
BD76). The selection of blading options is limited to MCA and DCA type airfoils, 
however, because full blade design package is outside of the scope of the TADS contract. 
The coding in PREDESIGN has been left very general so that any future blading options 
can be added easily. When the blade profile window is invoked off of the main panel, every 
slice of the generated blade is displayed. For clarity, the user can turn off various slices by 
using the functions under the “Graph” pull-down menu. 

When the user is satisfied with a blade shape, it can written to the TADS blade 
definition file, casename . tdsblad. As with casename . rvtdesign file, the user must cause 
the writing of this file; PREDESIGN will not write it automatically. 

5.5 POST 

The TADS post processor {POST), is a stand-alone module accessible through the “Post” 
pushbutton off of the TADS main panel. It can be used to view aerodynamic and 
convergence history data for ADPAC and RVCQ3D computations. 

Figure 5.10 shows the main panel of the POST module. By default, the program 
searches the working directory for TADS aerodynamic data file, casename . tdsaro, and 
the grid index file, casename .tdsaxi. From the main panel, the user chooses to read the 
data files needed to calculate the aerodynamic results for a given solver. 

Like in PREDESIGN , every plotting panel (main or pop-up) has a “Graph” 
pull-down menu for general plot manipulation 

5.5.1 Averaged Quantities in POST 

When any solution file is read into POST , several averaged values are calculated. There 
are two types of averages: circumferential and total. The circumferential averages are 
created by averaging across the blade pitch so that a 2-D, meridional representation of the 
data is created for each blade row. Total averages are created by spanwise averaging the 
circumferential averaged values. The resulting data for a given block is then a line of total 
averages vs. axial location. All quantities in POST are mass averaged. Since the number 
of available averaged quantities is large, the user is directed to one of the profile pop-up 
windows for the full listing. Part of the listing can be seen in Figure 5.12 

The “Radial Profiles” pop-up window displays circumferential averages vs. radius at 
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Figure 5.10: Main panel in POST showing the meridional projection of the axisymmetric 
throughflow grid. 


an i location specified on the main panel. Figure 5.11 shows the window with relative 
total pressure as the selected data. The data is selected under the “Data” pulldown menu 
shown activated in Figure 5.12 (where the user is changing to absolute total pressure). 
The user has the option of changing the current row and i location and updating the data 
accordingly. Additionally, the “Continuous Updating” toggle under the “Data” panel may 
be set to update the pop-up panel plot immediately. The “Axial Profiles” pop-up window 
displays total averages vs. axial location. Its appearance and functionality is nearly 
identical the radial profile pop-up. It also can be set to update automatically to a change 
in the current row value. 

5.5.2 Convergence Histories 

POST has the ability to view different convergence histories from the various TADS flow 
solvers. When the “Convergence History” option is selected under the “Windows” option 
off of the main panel, a pop-up window with four plot areas appears. Under the “Data” 
panel, the user has the option of viewing convergence histories of: 

1. Axisymmetric A DP AC. 

2. Blade-to-Blade ADPAC. The particular blade row displayed depends on the value of 
the row slider on the main panel. 

3. RVCQ3D. When this option is chosen, a small dialog window with a pull-down menu 
appears so that the user can specify the slice the user can specify the slice . 

For the ADPAC convergence histories, RMS and maximum residual error, mass flow 
in and out, total pressure ratio, and adiabatic efficiency are plotted against iteration 
number as shown in Figure 5.13. For RVCQ3D histories, all of the plots are the same 
except total temperature convergence is in place of adiabatic efficiency in the fourth plot. 
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Figure 5.11: Radial profile panel in POST for an axisymmetric ADPAC computation showing 
absolute total pressure. 
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Figure 5.12: Radial profile panel in POST for an axisymmetric ADPAC computation showing 
absolute total pressure. Here, the pull-down menu for different data types is shown activated. 
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Figure 5.13: Convergence histories panel in POST for an axisymmetric ADPAC computation. 
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Chapter 6 

Modification of TADS 


The TADS system is built on program modules with data transfer via files and flexible 
data structures. This architecture was adopted to minimize the effort required to extend 
or modify the system. The TADS system is divided into two parts: the GUI and the 
program modules. The program modules are loosely coupled to one another through files 
and are separate executables from the GUI. The GUI is more tightly coupled with data 
sharing through C structures. Object oriented programming concepts were employed to 
maximize modularity in the GUI. The program modules written specifically for the TADS 
system are modular, but the flow solvers and grid generators are used as received from the 
authors. Details about the program modules are found in the chapter "Analysis 
Coupling”. The GUI calls the program modules via the C “system” function, which forks 
a new process as a child of the GUI process in the UNIX system. 

6.1 Program Module Modifications 

Program modules can be added to the TADS system, but some modification to the GUI 
and the module source code will be required. This section deals with the modifications 
required to the program module itself. 

The required modifications to program modules are normally straightforward. The 
program module should perform I/O to named files following the casename .extension 
standard, should read and write mesh and flow data to PLOT3D style files using the SDB 
library, and should take all required input from files, rather than from screen input. All 
I/O that does not use the SDB library should be ASCII text. 

Of course, there are exceptions to the above rules. The blade-to-blade analyses are 
run in subdirectories of the main directory, and the file naming convention is relaxed in 
the subdirectories. Also, some programs are inherently interactive (e.g. TIGGC3D), and 
naturally require keyboard and mouse input. 

Program modules with their own graphics or graphical interfaces are a special case. 
The ideal situation is for graphics in a program module to be programmed in X-Windows 
using the Motif widget library. These programs will be fully portable across all machine 
types supported by the GUI itself. Programs using strictly XForms graphics calls are also 
portable. Program modules with Silicon Graphics GL or other proprietary graphics 
library routines will generally limit the portability of the module. Obviously, portability is 
not an issue in homogeneous systems of workstations. Also, GL applications can be run 
on remote SGI machines so long as they are displayed on a local SGI machine. 
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Currently, there are very few places in the TADS system where the user can specify 
contradictory input between program modules. One objective of any extension of the 
system should be to prevent contradictions with existing data or programs. This could 
easily occur for program modules with their own graphical interfaces. For example, 
T1GGC3D has its own interface and takes most of its input from a file. When TIGGC3D 
is executed, the user must specify the name of the input file to load the data, and must 
also specify the name of the output grid. These names must be the ones that other 
program modules expect in the TADS system, or the other program modules will not find 
their input files. For example, the ADPAC Q. ow solver expects the mesh to be in a file 
called casename.mesh. There is no simple means to enforce the TADS requirement for file 
names in TIGGC3D. This is a fairly minor point, but it illustrates how two uncoupled 
interfaces can lead to multiple specifications of the same parameters and contradictions 
between modules. If a new program module calls for interactive input of data which is 
already known to the GUI, a mechanism needs to be developed for the GUI to output the 
required information to a file, and for the program module to use the contents of that file 
as the default values in its interface. Otherwise, the user must be educated about the 
connections between the new module and existing modules in TADS. 


6.2 Adding Program Modules to the GUI 

A number of modifications need to be made to the GUI to add a program module. These 
consist of creating an input panel, adding the program module to the list in the main 
panel, creating subroutines to read and write the program module input files, and 
updating the global parameters. 

6.2.1 Creating an Input Panel 

The object oriented philosophy used in the GUI greatly simplifies the task of generating 
new a new input panel. The best procedure is to make a copy of a similar panel and 
modify it for the new application. 

Since the blade-to-blade tasks are the most likely place for new modules to be 
added, the RVCQ3D input panel will be used as an example of how to create a new panel. 
The RVCQ3D input panel code is called rvcq3dgen.c in the gui subdirectory of the TADS 
system. In this file are many variables which start with the letters “rvc” . A three letter 
prefix of the new application should be chosen to replace “rvc” in the variable and 
function names. This will insure that all new variable and function names are created, and 
that there will be no side effects between functions. There are many other variables in the 
code, but they are either global already, or are local to the RVCQ3D input panel code. 


Action Buttons 

For every panel there is a structure for the action buttons named BTNS-DATA. There is 
also a manifest constant (RVC_BTN_CNT in rvcq3dgen.c) which is defined to be the 
number of action buttons on the panel (6 for RVCQ3D). The BTNS-DATA structure 
defines the widget name and the placement of each action button. The specific form of 
this and all other data structures is found in the guilib subdirectory in a file called ltds.h. 
The actions of the buttons are defined in the function “rvc_inp_dec_pbCB” . The 
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BTNS-DATA structure and call back function generally do not require modification, 
except for changing the variable names as discussed above. 


Input Panel Data Structures 

There are two data structures which need to be tailored to the new module: 
GROUP-DATA and GROUP-PNTRS. These structures control the names, contents and 
behaviors of the individual parameter widgets on the input panel. The manifest constant 
“RVC-CNT” sets the number of input groups to be displayed on the input panel. The 
groups are arbitrary divisions of the input parameters, which are grouped and titled on 
the input panel. For RVCQ3D the groups correspond to the members of each input 
namelist. If the FORTRAN namelist style input is used in the program module, the input 
groups should be defined by the namelist members. Each group can have as many as 30 
parameters associated with it, as defined by the MAX-CELLS constant in the file ltds.h. 
The constant “RVC-CNT” is defined in the file constants.h. A new constant needs to be 
defined for the new panel in the form of “RVC-CNT” (use the three letter abbreviation 
chosen above). 

For each input group there are two sets of parameters encased in curly braces. The 
first set of parameters describes the characteristics of the group: the group title, namelist 
name (if applicable), position, size and margins, the number of input variables in the 
group, and the number of columns to be used by the widgets on the input panel. The 
second set of parameters is repeated for each input variable. The first thiee parameters 
are the variable name and two widget id parameters. The widget id parameters are set 
internally by the GUI and the user should initialize them to 0. The fourth parameter is a 
Boolean variable which determines whether the widget is active (editable) or not. 1 his 
parameter may be reset internally, but the specified value is used initially. 

The fifth parameter determines the behavior of the widget for slice-dependent input 
panels. A value of 0 means that the widget is active or inactive regardless of whether the 
panel is in “All Slices” mode, or is set to a specific slice. A value of 0 effectively means 
that the fourth parameter controls the behavior of the widget (used for slice- independent 
data). A value of 1 means that the widget is active in “All Slices” mode and inactive for 
any individual slice. Conversely, a value of 2 means that the widget is inactive in “All 
Slices” mode and active for any individual slice. 

The sixth, seventh and eighth parameters are values of the input variable. The sixth 
parameter is a pointer to the current value of the input variable. The seventh parameter is 
the default value of the input variable. The eighth parameter is used internally to 
determine whether or not the value has been changed on the input panel. This parameter 
should be initialized to the default value. 

The ninth parameter is the number of decimal places to be displayed in the input 
panel. The number of decimal places is also used when generating the input file for the 
program module. The tenth and eleventh variables are pointers to the minimum and 
maximum acceptable values for the input parameter. 

The twelfth parameter specifies the type of data range checking to be performed. A 
value of 0 means no data checking. A value of 1 means check a range between the 
minimum and maximum. A value of 2 means the input value must be greater than or 
equal to the minimum value. A value of 3 means the input value must be less than or 
equal to the maximum value. 
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The thirteenth parameter specifies the type of widget to be displayed on the input 
panel. A value of 0 means that a text box will be displayed. A value of 1 indicates a 
pulldown menu, and a value of 2 specifies a toggle button. 

The GROUP-PNTRS data structure has a record for each input variable divided 
into groups like the GROUP-DATA structure. The parameters in the GROUP-PNTRS 
structure are the pointed-to locations of the pointers in the GROUP-DATA structure. The 
three parameters are the current value, minimum and maximum for the input variable. 
The current value is a placeholder for a variable which is set internally, and should be 
initialized to 0. The minimum and maximum values should be set to the valid limits of the 
parameter whenever possible. In the event that the range is unknown, the values should be 
set to 0, and the data checking parameter in GROUP-DATA (twelfth) should be set to 0. 

The reason for the GROUP-PNTRS structure is that it provides a convenient 
mechanism for creating and using the database files associated with the slice-dependent 
input panels. The contents of these databases are read and written directly from the 
GROUP-PNTRS structure. The whole GROUP-DATA structure is not part of the 
database because some parameters, such as the widget id, have different values for each 
execution of the TADS system. If these were part of the database, then the widget id 
numbers would be corrupted on restart. Other parameters are constant and need not be 
part of the written database. The GROUP-PNTRS structure avoids unnecessary storage 
and corruption of internally generated values. 


Implementing Callback Functions 

Once the new panel has been created, variable names changed, and data structures 
specified appropriately, the next step is to add callback functions. Callback functions are 
the pieces of code which perforin actions in response to various events. Examples of events 
are opening the input panel, quitting the input panel or pressing an action button. 
Without the callbacks, the input panel is not connected to the GUI or the program 
modules. 

Most of the changes to the new input panel function code required to implement 
callbacks are accomplished by the variable name changing described above. The bulk of 
the effort is in writing the functions required by the callbacks. There is a function for 
reading data from an existing input file and recomputing special input parameters, and a 
function for writing new input files. 

The file input function is called when the input panel is opened, and when the 
TADS system is initialized. The file input function obviously contains coding to read an 
input file for the program module. However, the values from an existing input file are not 
appropriate for some input parameters. In the case of the blade-to-blade flow analysis, the 
reference conditions, boundary conditions, and geometric information should be computed 
from values known in TADS , rather than used directly from an existing input file. 
Generally, if an input parameter can be computed, the computed value should be used 
rather than the read value. This eliminates the possibility of specifying conflicting data in 
the GUI. The computation of input parameters frequently requires reading other TADS 
files, and working with globally defined data (such as a grid size). 

Frequently, the file input function is written in FORTRAN, while the GUI is written 
in C. C codes can call FORTRAN subroutines provided that two issues are resolved. 

First, all elements in FORTRAN argument lists are passed by reference, and not by value. 
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Therefore, the C code must specify all arguments as pointers. For simplicity, current 
functions pass all arguments as float (real) values. If the actual argument is an integer, 
temporary variables are used inside the function, and assignments are made appropriately. 
It is not necessary to follow this strategy, but it simplifies the writing of the C statement 
to call the FORTRAN subroutine. Second, FORTRAN compilers use different naming 
conventions for modules, depending on the vendor. For example, the SGI compiler refers 
to subroutines by their name in lower case post-pended with an underscore. The IBM 
compiler can be forced to to the same, with compiler options. Other vendors use different 
naming conventions, and that affects the way that the C code calls the FORTRAN 
routines. Some experimentation may be required before the various modules will link into 
an executable. 

The file output routine contains coding to write an input file for the program 
module. If the program module uses namelist style input, the function punch-namelist 
can be used, following the model in rvcq3dgen.c. If not, then custom coding must be 
written and linked to the GUI. The above discussion about mixing C and FORTRAN 
applies here also. 


Modifying the Main Panel 

Changes must be made to the main panel source code main.c to add the program module 
to the appropriate component group. In the function “init_gui_input_panels’ is a case 
block which determines which input panel is initialized for each component group. The 
new module should be added here under the appropriate case. Similar changes must be 
made to a case block in the function “dec_btnCB” which initializes the program module 
input data in the “Edit/Run” and “Run” modes. The function “runCB” contains a case 
block which initializes the input data and runs the appropriate program module. Again, 
the new module needs to be added, following the example of other modules. There will be 
multiple changes to this function because there are multiple events which cause the 
execution of a program module. Also, prototypes of the new functions need to be added to 
the header section of main.c. 

6.2.2 Finishing the Installation 

The TADS system must know where the executables can be found for each supported 
platform. The source code for the new program module should be placed in the modules 
subdirectory with the other modules. Also, symbolic links to the executables should be 
placed in the apl subdirectory. At present, executables are required for SGI R4000 and 
R8000/R10000 workstations, and IBM RS/6000 workstations. 

This completes the addition of a new program module to an existing component 
group. Adding a new program module following an existing model can be accomplished m 
about a day by an experienced programmer. 


6.3 Component Group Modifications 

Adding a component group is a more complicated exercise, and may require new coding for 
which no model exists, depending on the function of the component. An example of a new 
component would be a blade shape generation code for the design system. The majority 
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of the effort will be in modifying main.c to handle the new capability. If the new task fits 
in one place sequentially in the work flow, the changes will mostly involve expanding 
existing decision blocks. On the other hand, if the new module is callable in many places 
during the analysis sequence, then whole new decision structures will be required. 

New interface routines may also be needed between the new component and existing 
components of the analysis. These routines should be placed with the program modules in 
the modules subdirectory. The common directory under modules is a valuable source of 
routines for reading and writing TADS files, and converting data between various 
coordinate systems. 

6.4 Adding New Host Types for Remote Execution 

Adding new host types is relatively straightforward. An example of this would be to add 
Cray computers to the list of supported execution platforms. This involves changing the 
configgen.c source code in the gui subdirectory. In the function “configuregen” is a case 
block which identifies the supported platforms (“Silicon Graphics”, “IBM”, etc.). The new 
host type should be added to this list, and the loop index should be increased to reflect 
the new choice. Also, the file config.h has an enumerated type “mach_types” which needs 
to be updated following the pattern of the case block modification. The maximum number 
of supported platforms is specified by the manifest constant “MAX _NO_MACHINES” in 
the file constants. h. 

The program modules are executed via “system” function calls from the GUI. The 
“system” is used to invoke the UNIX shell script rsh_tds from the apl subdirectory. The 
shell script tests to see which machine type is required, and creates the appropriate 
execution statement. The test logic must be updated to show the new machine type. The 
machine types correspond to the enumerated type mentioned above. The script interprets 
the type of input and output files required from the number of arguments received by the 
shell script. Some modification may be necessary to create the proper execution 
statement. The script then executes the statement on the local machine, or starts a 
remote shell to run on the specified host. 

6.5 Modifying PREDESIGN and POST 

There are many options in PREDESIGN and POST that have not been developed due to 
limited time and resources. Adding to either module is rather straight forward due to very 
modular framework upon which each module is based. 

Each module has a header file which contains most of the structure definitions for 
the data items. In PREDESIGN , it is named designstruct .h and in POST it is 
poststruct .h. Many of the structures are collections of data pointers for which memory 
is dynamically allocated as required by the problem size. Both programs have a main . c 
source file which initializes the pop-up windows and sets program defaults. By looking at 
the structure definition, the main.c file, and the source files for reading and manipulating 
data, the developer can see how to add a new type of data to either module. 

6.6 Makenuike 

Makcmnke is a UNIX shell script to create Makefiles for TADS program modules. It is run 
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in the source directory of a program module and creates a new Makefile named 
Makefile.new. 

Makemake offers many features for managing coupled codes. One difficulty in 
supporting multiple platforms is keeping the object files segregated in the source directory. 
Makemake applies different suffixes to the object files from each compiler to avoid 
problems with linking dissimilar objects. 

Also, targets are provided in the Makefiles for checking source codes into and out of 
the Revision Control System. RCS allows the evolution of a code to be tracked by 
managing different releases of each source code in a special subdirectory. Any previous 
release of a subroutine can be recalled so that older capabilities are always recoverable. A 
release numbering scheme enables incremental improvements to be distinguished from 
major new releases. All program modules written for TADS use RCS. 

A dependencies section is generated in the Makefiles so that if a file is updated, all 
objects dependent on that file will automatically be re-compiled when the next executable 
is made. Dependencies are identified in either the C or FORTRAN syntax. A reliable 
dependencies list greatly reduces the time (or uncertainty) involved with creating new 
executables. 

The ability to create archive libraries of subroutines is also incorporated into 
Makefiles created by makemake. These libraries are identified with the associated revision 
level of the code so that executables can be created easily for older releases. 

Program modules written for the TADS system share include files between modules. 
In each source directory, a symbolic link is made to the include files in the common 
directory. To avoid entering the include files into multiple RCS directories, the symbolic 
links should be removed before running Makemake. A UNIX shell script rmlinks 
accomplishes this job. Similarly, the script linkinc restores the links. 

Makemake requires a Makefile template. The resulting Makefile is effectively an 
edited version of the template. To create a different style of Makefile, the user simply 
supplies a suitable template. Makemake and the associated tools and templates are found 
in the TOOLS subdirectory. 
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Chapter 7 


Verification 


The coupled throughflow and blade-to-blade analyses have been successfully applied to 
five cases which will be reviewed here: NASA Rotor 67, NASA Rotor 37, the three stage 
578DX boost compressor, the two stage Purdue turbine, and a high speed turbine vane 
tested on a shock tunnel (the VBI turbine). These four cases represent vanes and blades 
from both compressors and turbines, and span the spectrum of turbomachinery flow 
conditions from incompressible to transonic. The purpose of these studies is to verify the 
operation of the TADS system. Results from the A DPA C throughflow solver are 
compared with the axisymmetric average of a full 3-D A DP AC solution or experimental 
data (when available). These tests demonstrate the performance of the body force, 
blockage, and throughflow loss model implementation in the throughflow analysis. 

7.1 NASA Rotor 67 

NASA Rotor 67 is a transonic fan which has been studied extensively both experimentally 
and analytically. The highly loaded rotor was tested by Pierzga and Wood at NASA 
Lewis in 1985, [16]. Analytical researchers have had difficulty matching the data from the 
experiments, leading to the conclusion that the reported “hot shape” of the airfoil was 
inadequate. Since then, a new “hot shape” for the rotor was generated from the cold 
coordinates using finite element methods at Allison, and subsequent analytical results 
were significantly better. This redefined “hot shape” was used in the current work. 

Contour plots of absolute total pressure are shown for the throughflow and 3-D 
analyses in the section “Verification of Body Force Formulation” ( 4.5.5). The 3-D and 
throughflow analyses have been rerun using finer grids, and those results are presented 
here. 

The analysis was run for three full iterations: that is, the throughflow analysis and 
blade-to-blade solvers were run three times each, updating the meridional and 
blade-to-blade stream surfaces each iteration. Figure 7.1 shows the relative Mach number 
contours from the throughflow analysis at each iteration. As seen, the shock spreads down 
the span of the airfoil and a radial gradient forms downstream of the airfoil as iterations 
progress. The changes are smaller between the second and third iteration, indicating that 
the total system is converging. The large change between the first and second iteration is 
largely due to changes in the mean stream surface near the leading edge. The mass flow 
varies with iteration, and is closest to the mass flow from the full 3-D Euler solution after 
the third iteration. The pressure ratio drops and the efficiency rises with each iteration. 
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The magnitude of the changes decreases between iterations (a fourth iteration was 
performed, but results are not shown because the results are identical to the third 
iteration). 

Figure 7.2 shows the comparison of the relative Mach number contours between the 
third iteration through TADS and the axisymmetric average of the full 3-D Euler solution. 
The general trends are the same between solutions, but the details are different. The 
contours upstream and downstream of the rotor are in good agreement. In the bladed 
region, the differences are much larger. To some extent, these differences are expected 
because of the different solution procedures used. In the full 3-D solution, there is a shock 
structure, but the axisymmetric average de-emphasizes the shocks because the shocks are 
not aligned with the circumferential direction. On the other hand, the throughflow 
analysis is incapable of producing an oblique shock because the flow is assumed 
axisymmetric. This explains why the strong shock is present in the throughflow solution 
and not in the axisymmetric average. The presence of the shock accounts for most of the 
difference between the two solutions. 

The throughflow solution is used primarily to provide the meridional streamline 
shapes and boundary conditions for the blade-to-blade analysis. If the upstream and 
downstream solutions are in good agreement, and the streamlines from the throughflow 
solution are close to the streamlines from the 3-D solution, then the differences between 
the solutions are not terribly important to the overall analysis. However, the shape and 
distribution of the streamlines have a first order effect on the blade-to-blade solutions. 

The rate of change of radius (dr/dx) and the rate of change of stream tube height ( dbjdx ) 
appear in the source terms in the quasi-3D analysis. Small irregularities in the streamline 
shape or the stream tube height can cause large differences in the blade-to-blade solutions. 
The amount of movement in the throughflow streamlines is usually a good indication of 
the convergence of a TADS iteration (i.e. the convergence between the throughflow and 
blade-to-blade solutions). A 1% (of span) change or less in radial location of any 
streamline in the bladed region was the criteria used in the Rotor 67 and most other cases 
in this report. 

Figure 7.3 shows the meridional streamlines computed three ways: from the 
axisymmetric average of the full 3-D Euler analysis, from the third iteration of the 
coupled throughflow and blade-to-blade system, and from purely geometric considerations, 
saying that flow is directly proportional to area. As seen, the streamlines from the TADS 
solution have nearly the same shape as streamlines from the axisymmetric average. The 
radial locations of the streamlines are slightly different, indicating that there is more flow 
near the tip in the full 3-D Euler solution. This relates to the differences in the shock 
structure between the two solutions. 

A second flow feature also affects the distribution of the streamlines in the 
meridional plane. In the blade-to-blade plane, there is a flow separation at the hub region 
of the rotor, Figure 7.4. The extent of the separation is influenced by two factors. First, 
the radial distribution of the streamlines sets the stream tube height in the blade-to-blade 
flow, which in turn, influences the diffusion near the trailing edge. Second, all of the 
results presented in this report are solutions of the Euler equations. Since the flow is 
inviscid, the separation seen in the solutions is largely a function of the artificial 
dissipation in the various codes. The artificial dissipation scheme in RVCQ3D produces 
more losses than the scheme in ADPAC. It turns out that the RVCQ3D solution is quite 
similar to the hub section of a full 3-D Navier-Stokes solution, because of the artificial 
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NASA Rotor 67 Throughflow Analysis 
Relative Mach Number 
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VALUES 



Second Iteration 
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2= 0.50( 
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Third Iteration 
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13= 1.6 
14= 1.7 


Figure 7.1: The relative Mach number contours show how the throughflow solution responded 
to changes in the mean stream surface between iterations. 
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NASA Rotor 67 
Relative Mach Number 
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Third Iteration Through Coupled Throughflow and Blade-to-Blade Analyses 
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Axisymmetric Average of Full 3-D Euler Solution 


Figure 7.2: The relative Mach number contours from the third iteration and the axisymmetric 
average of the full 3-D solution are in good agreement outside of the bladed region. The presence 
of the normal shock in the throughflow analysis accounts for differences in the blade row. 
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NASA Rotor 67 
Meridional Streamlines 



Meridional streamlines are computed three ways: 

1. Streamlines are assumed to be along lines of constant percent area 

2. Streamlines are computed from throughflow solution after three 

iterations through coupled throughflow and blade-to-blade analyses 

3. Streamlines are computed from axisymmetric average of a full 3-D 
Euler solution 

Figure 7.3: The meridional streamlines from TADS differ slightly from the full 3-D Euler 
streamlines because of differences in the shock structure between the two solutions. 
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Table 7.1: Comparison of TADS iterations with ADPAC 3-D Euler solution for NASA Rotor 
67 shows g ood agreement. 



Flow (lbm/sec) 

Pressure Ratio 

Efficiency 

TADS Iter. 1 

77.57 

1.781 

87.8% 

TADS Iter. 2 

76.73 

1.696 

90.9% 

TADS Iter. 3 

77.83 

1.692 

92.2% 

ADPAC 3-D Euler 

78.52 

1.695 

92.6% 


dissipation in RVCQ3D. The grids used in the blade-to-blade analysis are clustered near 
the airfoil surface, which exacerbates the problems associated with artificial dissipation in 
RVCQ3D. However, less refined meshes resulted in poor solution quality near the airfoil 
surface due to lack of resolution. 

Figure 7.5 shows the comparison of the midspan sections from the blade-to-blade 
analysis and the full 3-D Euler solution. The agreement between these solutions is not 
particularly good, for many of the reasons already discussed. The shape of the midspan 
streamline is different between the throughflow analysis and the full 3-D Euler analysis 
(see Figure 7.3). In transonic flow, small differences in flow area can have a dramatic 
effect on the location and strength of shock waves. In fact, in the first iteration through 
TADS , it was necessary to use the streamline definition based purely on geometry in order 
to get the blade-to-blade analysis to converge on some streamlines. The mean 
blade-to-blade stream surface was based on the mean camber line and Carter’s rule in the 
first iteration, because no blade-to-blade solution was available at that point. This stream 
surface was not correct, and resulted in inaccurate positions of the meridional streamlines 
found from the throughflow solution. The blade-to-blade analysis was not able to find a 
stable solution along some of these meridional streamlines. 

Figure 7.6 shows the comparison of the tip sections from the blade-to-blade analysis 
and the full 3-D Euler solution. These solutions are in rather good agreement both 
qualitatively and quantitatively. Again, the larger wake in the RVCQ3D solution is the 
result of the higher dissipation near the blade surface resulting from the damping scheme 
in RVCQ3D . The tip solutions are less influenced by the streamline definition from the 
throughflow analysis because only the blockage is different between the solutions. The 
location of the hub and tip streamlines* are fixed to the flow path definition. In light of 
this, it is expected that the hub and tip solutions would be in better agreement with the 
full 3-D solution than the interior streamlines. 

Generally, the TADS solution of NASA Rotor 67 shows that the coupling of the 
program modules within the TADS system is correct. Boundary condition information is 
properly passed between the various codes, and the conversions between the 
non-dimensionalization schemes used in the codes are correct. Table 7.1 shows the 
comparison between successive iterations through TADS and the ADPAC 3-D Euler 
solution for Rotor 67. The agreement between the overall performance quantities in TADS 
and the 3-D Euler calculation is quite good. This is remarkable in that there are 
significant local differences between the various solutions, as discussed above. 


98 


INI ASA/CR-1 999-206603 




NASA Rotor 67 
Relative Mach Number 


VALUES 



RVCQ3D Blade-to-Blade Euler Solution 
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Full 3-D Euler ADPAC Solution 
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Hub Section 


Figure 7.4: The relative Mach number contours at the hub section are similar, but significant 
differences arise because of the separation at the trailing edge in the RVCQ3D solution. 
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NASA Rotor 67 
Relative Mach Number 
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Full 3-D Euler 
ADPAC Solution 


RVCQ3D Blade-to-Blade 
Euler Solution 


Midspan Section 

Figure 7.5: The relative Mach number contours at the midspan section are different because 
of differences in the meridional streamlines and stream tube heights between the solutions. 
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NASA Rotor 67 
Relative Mach Number 


VALUES 


1= 0.000E+C 



Full 3-D Euler ADPAC 



Tip Section 


Figure 7.6: The relative Mach number contours at the tip section are in very good agreement. 
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Trailing Edge Total Pressure Profiles 

NASA Rotor 67, pexit = 1 .04 



Figure 7.7: Trailing edge total pressure profiles for Rotor 67 showing comparison of 3-D ADPAC 
inviscid and viscous solutions with the 2-D ADPAC loss model solution. 

7.1.1 Rotor 67 with Losses 

An additional test of the Rotor 67 case was performed with the ADPAC throughflow loss 
model activated. Total pressure loss coefficient values were obtained from an ADPAC 3-D 
Navier-Stokes solution. Unlike the stator validation case (see Section 4.5.7), the Rotor 67 
case is much more complex and the TADS result does not match the full 3-D 
Navier-Stokes solution as' well (see Figure 7.7). However, the Rotor 67 case illustrates that 
the loss modeling can have a marked effect on the shock structure through the blade row. 

A key area of concern when the loss model implementation was being researched 
was proper resolution of shock structure for transonic cases. The first issue, which was 
also a problem in inviscid flows, was that the shock could never be properly defined in the 
axisymmetric framework because a true three dimensional shock is not aligned with the 
theta coordinate direction (this was discussed in the previous subsection). The second 
issue was that for a passage shock, the axial location depends strongly on the thickness of 
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NASA Rotor 67 Relative Mach Number for 2-D and 3-D ADPAC solutions 





2-D with Viscous Loss Model 

2-D Inviscid (Stream surface from 3-D) (Stream surface from 3-D) 

Figure 7.8: Plot of relative Mach number contours for NASA rotor 67 using four different 
calculation methods. 

blade boundary layers which serve to decrease the effective area that the flow passes 
through. The second issue was pertinent because even for a full three dimensional 
solution, the presence of boundary layers results in a shock location which is drastically 
different than an inviscid flow (see the top two plots in Figure 7.8). The loss model 
doesn’t change the blockage that the flow experiences through the passage (it is still just 
metal blockage). Hence, there was concern that no matter how much loss was added to 
the equations via the body force source terms, the axial location of the shock would still 
be same as the purely inviscid solution. However, as Figure 7.8 shows, the loss model 
does predict a change in the shock location that is comparable to the location change 
experienced by the three dimensional solution. This phenomena could be explained by 
considering how the loss model is formulated. If the body force source term acts as a 
retarding force to the flow, then the amount of momentum along each streamline is 
changed. This effect is similar to reduction in allowable flow area created by the blade and 
endwall boundary layers in a three dimensional flow. It should be noted that the 
axisymmetric ADPAC grids used for the inviscid and loss model computations are 
identical (i.e. both are mean stream surfaces derived from the same viscous 3-D solution). 
Only the presence of the loss model source terms creates the change in shock location. 


7.2 NASA Rotor 37 

Rotor 37 is a high speed fan which has been studied extensively both experimentally and 
analytically. It has been the subject of many so-called ” blind” CFD validation tests 
because of the difficulty of predicting the flowfield accurately. It makes a very difficult test 
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case for TADS because it is designed to be supersonic from hub to shroud. The design 
total pressure ratio is 2.106, mass flow is 44.51 lbs., the rotation rate is 17,188 rpm, hub 
leading edge radius 7.0 inches, and the hub-to-tip ratio is 0.705. Because the design is so 
sensitive to changes in blade shape, the TADS blade definition file uses 21 spanwise points 
instead of the usual 11. This verification section details full TADS iterations of Rotor 37 
with and without losses. For design mode computations, see Section 4.5.6 on design mode 
validation. 

7.2.1 NASA Rotor 37 Without Losses 

Like the Rotor 67 case, the Rotor 37 case was run for three full TADS iterations. 

Figure 7.9 shows the relative Mach number contours from the throughflow analysis at each 
iteration. For each iteration, the passage shock covers the entire span of the blade. There 
is a large discrepancy between the first and second iterations, but the third contour plot 
shows that the overall solution is converged. As an additional check of convergence, the 
streamlines from the SLICER program are plotted in Figure 7.10 for each TADS iteration. 
It can be seen that the second and third streamlines are nearly identical. Just as in the 
Rotor 67 case, the large difference between the first and second iterations is largely due to 
changes in the mean stream surface near the leading edge. This difference creates a 
change in incidence which alters the entire flowfield downstream of the leading edge. 

7.2.2 NASA Rotor 37 using B2BADPAC 

Rotor 37 was one of the first tests of the blade- to-blade ADPAC module ( B2BADPAC ). 
Although the creation of B2B ADPAC was motivated primarily by problems encountered 
in multistage computations, the problems associated with the high pressure ratios in fan 
cases like Rotor 37 were also a reason. When blade-to-blade computations were attempted 
on Rotor 37 using RVCQ3D, the more than 2-to-l pressure ratio made the solution go 
unstable. RVCQ3D could be made to work by incrementally increasing the back pressure 
and restarting, but this approach seemed rather impractical in the TADS framework. 
B2BADPAC performs blade-to-blade computations on Rotor 37 without having to adjust 
back pressures or input parameters. Figures 7.11, 7.12, and 7.13 shows relative Mach 
number contours for hub, midspan, and tip regions respectively. It should be noted that 
the blade stagger angle of the 3-D Navier-Stokes solution for the hub relative Mach 
number comparison in Figure 7.11 may be a little off because contours had to be taken 
from a location slightly away from no-slip wall. 

The strong shocks (even in the hub region) in the flow are probably responsible for 
leveling-off of convergence seen in Figure 7.14. This convergence history is for the second 
TADS iteration blade-to-blade solution. 

7.2.3 NASA Rotor 37 With Losses 

The validation of the loss model for Rotor 37 was very similar to Rotor 67. Figure 7.15 
which compares the total pressure loss at the trailing edge for various calculation 
methods, shows that, although the loss model brings the base, inviscid solution closer to 
the 3-D Navier-Stokes profile, there is still considerable discrepancy in results. 

Figure 7.16 compares relative Mach number contours from various calculation 
methods. It can be seen that, just as in the Rotor 67 case, the loss model alters the shock 
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NASA Rotor 37 Throughflow Analysis 
Relative Mach Number 
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Figure 7.9: Relative Mach number contours show how the Rotor 37 throughflow solution 
responded to changes in the mean stream surface between iterations. 
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Figure 7.10: The near identical middle streamlines from the second and third TADS iterations 
shows that the run is converging. 
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Figure 7.11: The relative Mach number contours at the hub section for Rotor 37 are only in 
fair agreement due to the presence of a hub boundary layer in the 3-D Navier-Stokes solution. 
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Figure 7.12: The relative Mach number contours at the mid section for Rotor 37 are in very 
good agreement. 
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Figure 7.13: The relative Mach number contours at the tip section for Rotor 37 are not in very 
good agreement due to tip clearance effects. 
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Iteration Number Iteration Number 


Figure 7.14: Convergence history of the Rotor 37 blade-to-blade solution using the B2BADPAC 
module. 
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Total Pressure (psi) 


Trailing Edge Total Pressure Profiles 


NASA Rotor 37, pexit =1.15 



Figure 7.15: Trailing edge total pressure profiles for Rotor 37 at design back pressure comparing 
various solution methods. 
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NASA Rotor 37 Relative Mach Number for 2-D and 3-D ADPAC Solutions 



Inviscid 3-D (axisymmetrically avg.) 




Viscous 3-D (axisymmetrically avg.) 



2-D with Viscous Loss Model 
(Stream surface from 3-D) 


Figure 7.16: Plot of relative Mach number contours for NASA rotor 37 using four different 
calculation methods. 


location in the direction of the 3-D Navier-Stokes solution. 

The Rotor 37 results, like the Rotor 67 results, show that even with several TADS 
iterations and a working loss model, it is difficult to effectively match a full 3-D 
Navier-Stokes solution. With oblique passage shocks and large blade stagger angle, many 
of the shortcomings of the S1-S2 approach become apparent. For these cases, the user 
must be aware of the limitations of the axisyinmetric and blade-to-blade assumptions and 
care must be taken when analyzing and interpreting results. 


7.3 578DX Boost Compressor 

The 578DX booster is a three stage compressor (with IGV) designed for an advanced 
propfan program in the mid 1980’s. The booster was the front LP compressor feeding a 
HP core compressor. The booster was designed to provide flexibility for a wide range of 
engine power classes while still retaining a common core. A cross section of the LP-HP 
combination is shown in Figure 7.17. The 578DX booster has a corrected flow of 77.4 
lbui/s (31.92 lbm/s actual), a total pressure ratio of 2.14, a rotation rate of 11091 rpm, an 
adiabatic efficiency of 88.6%, a hub radius of 5.96 inches at the IGV leading edge, and a 
hub-to-tip ratio of 0.51. 

The 578DX boost compressor was chosen as a validation case since extensive 
measured interstage and discharge data were available. Additionally, many of the design 
philosophies (loadings, setting angles, aspect ratios, etc.) are representative of current 
compressor design. 

Because of the number of blade rows and the large amount of data created by a run 
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Figure 7.17: Cross section of the 578DX boost compressor attached to the front of an HP 
compressor rig. 
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Table 7.2: Comparison of ADPAC mass flow rate, total pressure ratio, and efficiency between 


TADS iterations shows that the throughflow and blade-to-blade so 



Flow (lbm/sec) 

Pressure Ratio 

Efficiency 

TADS Iter. 1 

32.780 

2.220 

78.6% 

TADS Iter. 2 

33.743 

2.199 

94.2% 

TADS Iter. 3 

34.282 

2.216 

94.4% 

TADS Iter. 4 

34.271 

2.215 

94.9% 


utions are converged . 


like the 578DX, only pertinent areas of the flowfield are examined below. For example, for 
streamline comparison between TADS iterations, only the first rotor is used. Rotor 1 was 
chosen because it contains a mild shock and the highest overall pressure ratio and thus is 
probably the most critical area of the simulation. 

Two separate cases were run: one using ADPAC in a strictly inviscid mode and 
another using the throughflow loss model. The latter case is compared to the design 
operating point of the actual compressor rig. 

7.3.1 578DX Boost Compressor Without Losses 

Figure 7.18 (top) shows the 578DX boost compressor axisymmetric grid created by 
TIGG. The bottom figure shows the mean stream surface definition applied by the 
BOI) YF module using the mean camber calculated from the casename . tdsblad. For the 
first TADS iteration, Carter’s deviation rule was not applied. Using Carter’s rule might 
have enhanced convergence, but it was felt that running the case using only the basic 
options was a better test of the multistage capability in TADS . 

Figure 7.19 compares relative Mach number contours from the throughflow solution 
for four TADS iterations. It can be seen that the solution is essentially unchanged 
between the third and fourth iterations. As an additional check of convergence of the 
TADS run, streamlines through Rotor 2 are shown in Figure 7.20. As a final convergence 
check, overall mass flow and performance quantities for each iteration are shown in 
Table 7.2. The 578DX case shows that the TADS coupling scheme and the proper 
communication of boundary condition information is correct for multistage computations. 

7.3.2 578DX Boost Compressor With Losses 

In addition to checking the convergence of a TADS run, comparison to a full 3-D 
Navier-Stokes CFD solution and data was made. For these comparisons, total pressure 
losses from a streamline curvature code were applied at the trailing edge of each blade 
row. Convergence of the TADS run was almost identical to the case with no losses. 

Figure 7.21 compares relative Mach number contours for the TADS throughflow 
solution (with losses) and an axisymmetric average of a full 3-D Navier-Stokes solution. 
Results show that the overall solutions agree rather well. There is some smearing of the 
shocks in the 3-D solution because of the misalignment with the axisymmetric direction 
(similar to the Rotor 37 and 67 cases). A comparison with test rig data was also made as 
shown in Figure 7.22. It can be seen that the throughflow loss model effectively removes 
energy (total pressure) from the flow and drives it closer to the test data. However, total 
pressure at the booster exit is still over-predicted by TADS . Many of the discrepancies 
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Figure 7.20: Comparison between meridional streamlines of the 4 TADS throughflow iterations 
shows that the solution is already very well converged after the second iteration. 
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578 DX: comparison with 3-D Navier Stokes 
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Figure 7.21: The relative Mach number contours for the 578DX boost compressor from (Top) 
the TADS throughflow solution with loss modeling and (Bottom) an axisymmetric average of a 
3-D Navier-Stokes solution. 


between the solutions and test data can be attributed to the difference in mass flow as 
seen in the speedline plot in Figure 7.23. For the speedline plot, the 578DX booster was 
throttled through a range back pressures. The overall shape of the total pressure and 
efficiency lines are very similar, but the difference in mass flow affects the operating point. 


7.4 Purdue Low Speed Turbine Rig 

The Purdue Low Speed Turbine Rig was chosen as a test case because of the high camber 
of the airfoil. The flow is basically incompressible, with a peak Mach number of around 
0.3. The flowpath is annular with a hub radius of 7.1 inches and a hub-to-tip ratio of 
0.740. Total-to-total expansion ratio is 1.15, mass flow is 6.0 lb/s, design efficiency is 
90.3%, and wheel rotation speed is 2500 rpm. 

Two separate cases were run: one using ADPAC in a strictly inviscid mode and 
another using the throughflow loss model. Each case is compared to the design operating 
point of the rig. 

7.4.1 Purdue Turbine Without Losses 

Figure 7.24 shows relative mach number contours for the throughflow solution in the first, 
second, and third TADS iterations. The mean camber line was used as the initial mean 
stream surface because Carter's deviation angle rule is not applicable to turbine airfoils, 
.fudging from the downstream Mach number distribution, the third iteration would be an 
acceptable stopping point for normal design work. 
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Exit Total Pressure Ratio Comparison 


578DX at 1 00% Design Back Pressure 



Figure 7.22: Trailing edge total pressure profiles for the 578DX boost compressor from the 
purely inviscid TADS throughflow solution, the TADS throughflow solution with losses, and test 
rig data. 
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Figure 7.23: Performance data at 100% speed for the 578DX boost compressor showing the 
TADS throughflow solution with losses, 3-D Navier-Stokes data from ADPAC, the design intent 
from a streamline curvature code, and rig data. 







Figure 7.24: The relative Mach number contours from each iteration show that the TADS 
system is converged after three iterations. 
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Figure 7.25 shows the blade-to-blade solutions for the hub, mean and tip sections of 
the Purdue Low Speed Turbine Rig first rotor. This turbine was designed to be 
two-dimensional: there is little radial migration of flow, and the loadings at each section 
are approximately the same. There is very little difference between the solutions for each 
section, indicating that the TADS solution is consistent with the design intent. 

The TADS results show the expected behavior for the Purdue Low Speed Turbine 
Rig. This case has much greater blockage than the compressor cases presented above. The 
success of the analysis indicates that the blockage terms are performing as designed in the 
multistage throughflow analysis. 

7.4.2 Purdue Turbine With Losses 

As an additional test of the loss model in a multistage environment, three 
TADS iterations were run with total pressure loss definitions for all four blade rows. 

TADS convergence was almost identical with the previous, no-loss case. Results, however, 
show that, losses have the desired effect of bringing the purely inviscid solution closer to 
the experimental values. Figure 7.20 compares the absolute total pressure profiles from 
the experimental rig, a TADS run without losses, and a TADS run with losses. It can be 
seen that even with losses, TADS is still overpredicting total pressure and that including 
losses only has a small effect on the predicted results. A good deal of the discrepancy 
between TADS and the experiment can be attributed to the large endwall blockage that is 
present in a turbine. This blockage reduces flow and changes the operating point of the 
machine just like in the 578DX case. 

7.5 VBI Turbine Vane 

The fifth test case selected to verify the operation of the TADS system is the Vane-Blade 
Interaction (VBI) turbine vane. The VBI turbine is a single stage transonic turbine, which 
spins at 11,400 rpm in an annular flowpath with a leading edge hub radius of 8.73 inches 
and a hub-to-tip ratio of 0.82. The steady and unsteady performance of the VBI turbine 
has been investigated at the Calspan Research Center by M. Dunn. [7] documents the 
geometry, the experimental apparatus, and presents both experimental and analytical 
aerodynamic data for the VBI turbine. The VBI vane makes a good test case because of 
the significant airfoil thickness and the transonic flow. 

The TADS system was run for four full iterations. Figure 7.27 shows the Mach 
number contours from the throughflow analysis after each iteration. The solution is 
converged in three iterations, but the first iteration is a reasonable approximation to the 
converged solution. The meridional streamlines found from the throughflow analysis after 
the first and fourth iterations are shown in Figure 7.28. The only difference in the 
streamlines between the first and fourth iterations is near the trailing edge. In turbine 
airfoils, however, the trailing edge is the critical area because the throats are typically set 
at the trailing edge. Changes in the stream tube height at the trailing edge can have a 
significant effect on the Mach number levels seen in the blade-to-blade solutions. In this 
case, the differences in the midspan solutions between the first and fourth iterations are 
minimal, Figure 7.29. 

Table 7.3 shows the mass flows after each iteration through TADS and from the 
ADPAC 3-D Euler solution for the VBI vane. The mass flow reaches the converged value 


122 


NASA/C R-1 999-206603 




\ 

Tip Section 

Figure 7.25: The relative Mach number contours from the blade-to-blade analysis show that 
the loading is essentially constant from hub to tip. 
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Absolute Total Pressure Profiles 
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Figure 7.26: Profiles of absolute total pressure for the Purdue turbine experimental data and 
two TADS computations. 
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VBI Turbine Vane 
Throughflow Analysis 


VALUtS 




Second Iteration 



Fourth Iteration 

Mach Number 


Figure 7.27: The meridional Mach number contours from each iteration of the throughflow 
analysis show that the TADS system is converged after three iterations. 
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VBI Turbine Vane 
Meridional Streamlines 


Leading 

Edge 




Meridional streamlines are computed two wavs: 

Iteration 1. Streamlines are computed from the throughflow solution, 
which used the mean camber line as the mean stream 
surface 

Iteration 4. Streamlines are computed from the throughflow solution, 
which used the mean stream surface calculated from the 
blade-to-blade solutions in Iteration 3. 

Figure 7.28: The meridional streamlines from the first iteration are a good approximation to 
the final solution. 
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VBI Turbine Vane 
Mach Number 




VALUES 

1= O.OOOE+C 
2= 0.100E+C 
3= 0.200 
4= 0.300 
5= 0.400 
6= 0.500 
7= 0.600 
8= 0.700 
9= 0.800 
10=0.900 
11 = 1 .000 
12 = 1.10 
13= 1.20 
14= 1.30 
15= 1.40 
16= 1.50 
17= 1.60 
18= 1.70 
19= 1.80 


Iteration 1 


Iteration 4 


RVCQ3D Blade-to-Blade Euler Solution 
Midspan Section 

Figure 7.29: The midspan Mach number contours from the blade-to-blade analysis are effec- 
tively the same between the first and fourth iteration of the TADS system. 
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Table 7.3: The TADS iterations show good convergence, and reasonable agreement with the 
ADPAC 3-D Euler solutio n for the VBI Turbine Vane. 



Flow (lbm/sec) 

TADS Iter. 1 

22.89 

TADS Iter. 2 

22.04 

TADS Iter. 3 

24.78 

TADS Iter. 4 

24.80 

ADPAC 3- D Euler 

23.67 


on the third iteration, consistent with the meridional Mach number contours presented in 
Figure 7.27. The converged mass flow is also in reasonable agreement with the 3-D Euler 
solution. 

Figures 7.30, 7.31, and 7.32 show the comparison between the RVCQ3D 
blade-to-blade solutions and the ADPAC 3-D Euler prediction for the hub, midspan, and 
tip sections, respectively. As seen, the solutions are generally in good agreement, although 
there are minor differences in the position of some contours. 


7.6 Summary 


In each test case, the TADS system predictions are reasonable, and agree with 3-D Euler 
and Navier-Stokes solutions at the same conditions. The good agreement demonstrates 
not only that the blade-to-blade solver is functioning properly, but that the system 
coupling is correct as well. The TADS system is a coupled system of quasi-3D solvers: the 
throughflow and blade-to-blade analyses both solve the governing equations in two 
dimensions, and rely on outside information to model the third dimension. The 
blade-to-blade analysis takes its boundary condition information from the throughflow 
analysis, and the throughflow analysis enforces flow tangency to the mean stream surface 
shape found by the blade-to-blade analysis in the bladed region. In order for the 
blade-to-blade results to agree with the 3-D results, the static pressure passed from the 
throughflow analysis must be correct. The static pressure in the throughflow solver is set 
by radial equilibrium at the grid exit. The radial equilibrium equation in the throughflow 
solver predicts the static pressure, accounting for swirl in the flow. 

The test cases presented here demonstrate convincingly that the coupling between 
the analyses in TADS is done correctly. Further, the TADS analysis is applicable to a 
wide range of problems in turbines and compressor airfoil design. There are some 
difficulties with transonic fans, due to the shock structure. Because the actual shock 
structure is not axisymmetric, the throughflow analysis does not predict the the same flow 
pattern as the axisymmetric average of a 3-D prediction in the bladed region. This affects 
the location of the meridional streamlines, and in turn, the blade-to-blade analysis. The 
TADS predictions are good within the limits of the assumptions in the analysis, but 
oblique shock waves are not modeled properly in an axisymmetric calculation. 

For test cases where the throughflow loss model is applied, results show that the 
addition of loss source terms in the governing equations for the axisymmetric solver 
effectively removes relative total pressure through the blade row. The lower exit total 
pressure profile created by the loss model matches the 3-D Navier-Stokes result better 
than the purely inviscid axisymmetric solution. Transonic blade row calculations show 
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VBI Turbine Vane 
Mach Number 


VALUES 



ADPAC Full 3-D Euler Solution 



1= 0.000E+C 
2= 0.100E+C 
3= 0.200 
4= 0.300 
5= 0.400 
6= 0.500 
7= 0.600 
8= 0.700 
9= 0.800 
10= 0.900 
11 = 1.000 
12 = 1.10 
13= 1.20 
14= 1.30 
15= 1.40 
16= 1.50 
17= 1.60 
18= 1.70 
19= 1.80 


RVCQ3D Blade-to-Blade Euler Solution 


Hub Section 

Figure 7.30: The Mach number contours from the hub section blade-to-blade analysis agree 
well with the 3-D Euler results. 
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VBI Turbine Vane 
Mach Number 



ADPAC Full 3-D Euler Solution 



VALUES 

1= O.OOOE+f 
2= 0.100E+C 
3= 0.200 
4= 0.300 
5= 0.400 
6= 0.500 
7= 0.600 
8= 0.700 
9= 0.800 
10=0.900 
11 = 1.000 
12 = 1.10 
13= 1.20 
14= 1.30 
15= 1.40 
16= 1.50 
17= 1.60 
18= 1.70 
19= 1.80 


RVCQ3D Blade-to-Blade Euler Solution 


Midspan Section 

Figure 7.31: The Mach number contours from the midspan section blade-to-blade analysis 
agree well with the 3-D Euler results. 
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VBI Turbine Vane 
Mach Number 


VALUES 




ADPAC Full 3-D Euler Solution RVCQ3D Blade-to-Blade Euler 


1= O.OOOE+C 
2= 0.100E+C 
3= 0.200 
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5= 0.400 
6= 0.500 
7= 0.600 
8= 0.700 
9= 0.800 
10= 0.900 
11 = 1 .000 
12 = 1.10 
13= 1.20 
14= 1.30 
15= 1.40 
16= 1.50 
17= 1.60 
18= 1.70 
19= 1.80 


Solution 


Tip Section 


Figure 7.32: The Mach number contours from the tip section blade-to-blade analysis agree 
well with the 3-D Euler results. 
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that even with the loss model, it is difficult to accurately match the full, 3-D Navier-Stokes 
result. This shortcoming, however, seems to be due more to the aforementioned difficulty 
in modeling oblique shock waves than to any deficiencies in the throughflow loss model. 

The test cases for the TADS design mode showed that a mean stream surface can be 
successfully created by enforcing an rVg distribution though a blade row. As a check of 
the accuracy of the design mode algorithm, the rVg distribution from an analysis mode 
run was used. The resulting mean stream surface from the design run is identical to the 
analysis mode mean stream surface. For subsonic transonic cases, a general rVg can be 
applied. For transonic and supersonic cases, however, the rVg distribution can produce a 
physically unrealistic operating condition or an unusual incidence situation that hampers 
convergence. 
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Chapter 8 

Conclusions 


A turbomachinery airfoil analysis system has been developed by coupling a throughflow 
analysis with a blade-to-blade analysis. This analysis, the Turboinachinery Analysis and 
Design System, TADS , enables a designer to analyze airfoil shapes without the expense of 
a full 3-D calculation. A GUI was developed to assist the user in controlling the work flow 
in the analysis. Input panels were developed for each task in the analysis, and capability 
was included to run each task on a remote host. Programs were developed to link the 
various grid generators and flow solvers, passing information between them by way of files. 
The system was designed to enable new codes to be added to the list of choices for any of 
the major tasks (e.g. grid generation, throughflow analysis, or blade-to-blade analysis). 

The throughflow analysis was developed by adding body force and blockage terms to 
the ADPAC code. These terms model the presence of the airfoil in the axisymmetric flow: 
the body force terms enforce a turning distribution, and the blockage term simulates the 
airfoil thickness. Convergence acceleration techniques such as multigrid and implicit 
residual smoothing were preserved in the throughflow analysis. The newly developed 
throughflow analysis was verified with simple test cases and with NASA Rotor 67. 

The total coupled analysis was applied to five test cases: NASA Rotor 67, NASA 
Rotor 37, the AST compressor fifth stage, the Purdue Low Speed Turbine Rig first rotor, 
and the VBI turbine vane. These cases spanned the flow speed regime from incompressible 
to transonic flow. The body force and blockage terms were verified with highly cambered, 
thick airfoils as well as thin low camber shapes. In each case, the TADS system converged 
to a reasonable solution, comparing favorably with 3-D Euler calculations performed at 
the same flow conditions. As a coupled system of codes, iteration is required to converge 
the TADS analysis. In all cases, TADS converged in three or fewer iterations through the 
coupled throughflow and blade-to-blade solutions. 

With the exception of flows with strong shock waves, the analysis has been shown to 
be a good approximation to a full 3-D analysis. TADS solutions compared well with full 
3-D solutions in terms of comparison with contour plots and massflow. However, 

TADS solutions were found to be only qualitative when examining total pressure ratio, 
efficiency, and overall performance. Many of the discrepancies in the TADS solutions were 
due to the presence of shocks (as mentioned above). However, another significant source of 
error when comparing to full 3-D Navier-Stokes solutions was caused by the lack of 
endwall boundary layers in TADS . Within these limitations, the TADS solution 
procedure is an effective way of examining the detailed flowfield of a turboinachinery 
design without the expense of a full 3-D solution. 
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Appendix A 

Loss Model Development 


A.l Loss Forces 

An entropy increase can be introduced into a flow by satisfying the continuity and energy 
equations while removing momentum from the flow. Physically, this removal of 
momentum corresponds to converting mechanical energy to thermal energy. 

Two problems where an increase in entropy and a corresponding decrease in 
momentum can be observed are within the boundary layer of an infinite flat plate and 
within a normal shock. Within an normal shock, the continuity and momentum equations 
are satisfied. However, momentum is lost by frictional processes in the shock. Note that 
for weak shocks, the entropy increase is small (a higher-order term) as is the momentum 
decrease. 

Within the boundary layer of an infinite flat plate, if one considers a rectangular 
control volume aligned with the flow, the streamwise momentum flux through the sides 
parallel to the plate are different. This can be seen by considering the slope of the velocity 
profile at the two endwalls of the control volume and the accompanying viscous transfer of 
streamwise momentum. Further, one can assume that the solution varies only in the 
direction normal to the plate. 

As part of the Second Law of Thermodynamics, the relationship between 
temperature, T, the change in entropy, ds, and the energy, dq, ( which is converted from 
mechanical energy to thermal energy as entropy increases ) is, 


T d. s = dq 

The total energy ( total enthalpy ) of the system remains the same. 

Suppose that along a streamline element of length dl a loss force, /-■ ( directed 
opposite the flow tangent ) is applied, then the work done is 


dq = — / T dl 

Combining the two equations above, we have along the streamline, 

T ds = —f T dl 


This equations gives the relationship between the entropy change, the amount of 
energy changed from mechanical to thermal energy, and the magnitude of the loss force 
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applied. The equation may also be expressed as 

rw • v« = -w • f T 

for a relative velocity, W, in a relative reference frame. 
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A. 2 Total Pressure Losses to Loss Forces 

These streamlines pass through a region which can correspond to a blade row or a 
combustor. Each blade has a specified design point total pressure loss.u; , for each 
streamline of the design, 


_ Pl\ ~ Pt-2 

u> = — 

Pl\ ~ Pi 

p' - P' r 

— _ Tidcal2 1 2 

iO — — zzr r 

Pt i ~Pi 


> 0 


> 0 


( — ) = T 
[ ds )p 


(—) =- 
{ dp u p 


(Stator) 


(Rotor) 




dh 




dp 

P 


( b to c is isentropic and c to a is constant pressure, in a Mollier diagram). The overbar in 
the above equations and the equations that follow denote averaged quantities. 


Hence along a streamline, 


A h= [' ^ = [ frdl^frAl 
Jb P J 

For the real gas determine an interpolant (dimensional), 

V-(h) — D\ + D 2 h + D^h 2 + D 4 h 3 + D b h* 

Pa 

satisfying, for isentropic variations, 

— = — (ti 2 )/— (hi) where f — = I dh — h 2 — h\ 

Pl Pa Pa Jp i P •'l 

Assume, 

^(11) = Di + D 2 Ti + Dih 2 + Dj? + D-Ji 

Pa 

h = J)E + p- ^p(Pi 2 ) 
h ' 0 = pE + p-^p(W-Wl 2 ) 

Non-dimensionalize and include these theta-average approximations. 


P-(h) = D\ + Dji + D-.fi 2 + Dji 3 + Dji 4 

Pa 

where the caret symbol denotes a non-dimensional quantity. For a more sophisticated 
form of the interpolant, factor out the ideal gas analytic form of the function, namely 
p a /iH. The non-dimensional factors are figured into the interpolation constants 
(D x - Dr,) and the resulting equation is (with the caret notation removed for clarity): 
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(h) — /t 3 j (I>i 4 - D 2 h 4 - D 3 / 1 2 4 - D,\h ' 3 + D$h A ) 

Pa 

For Keenan data from 400° - 700° R a least squares fit with this polynomial does 
30%-40% better. For Keenan data from 400° - 2400 °R where non-ideal features appear, 
this polynomial has errors two orders of magnitude smaller at low temperatures and about 
the same error at high temperatures. 

It may be sufficient to use 


if the temperature range is small. Currently, A D PA C does not allow for a variable specific 
heat ratio, so many of the interpolation routines for calculating the enthalpy change are 
beyond the complexity level required for this loss modeling. Hence, the simplified relation 
above is the one used for the throughflow loss model in ADPAC. The more complex 
modeling is presented here because it would be required in the presence of a more exact 
variable specific heat ratio formulation. 
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From total pressure loss to loss force in the absolute (stator) frame: 


P'i\ - Pt^ 

P Ti ~Pl 


>0 


Enthalpy, ho, is constant through a stator blade row. 


ho2 = ^01 


P Ti = Pi 


Pa Pa 


P Ti = P Ti — TPL ( i?n - Pi) 


~( h 02 idettl ) ~ ^7 ^( /l 02) 

Pa Pa 


Invert -2-(/i 0 2 , ,) with a newton scheme. Note that this can be unstable on start up if the 

Pq ' I U C (Z I 

initial guess is bad. 


/tAI h 02i dea i h(>2 


N AS A/CR-1 999-206603 


141 



From total pressure loss to loss force in the relative (rotor) frame: 


p T idca i 2 - p r 2 
P'i\ - Pi 


> 0 


P' Tl = Pi ~(4)/-(* i) 

Pa Pa 


Rothalpy, I = Iiq 




i is constant through a rotor blade row. 


—f y7 i 9 2\ 

^02 = «01 + -g- (^2 — r l ) 


Pa Pa 


P ,T< 

-(V 


f (4) 


7b 


Pa 


Invert ^-(/io 2 . t(cu( ) with a Newton Scheme. Note that this can be unstable on start up if 
the initial guess is bad. 


fr A/ = A/i = h’ 02ideal - h' 02 
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A. 3 Numerical Implementation 


In the efluxl.f routine in ADPAC, Ah is calculated (as above for rotors and stators) 
and divided by the axial length of the streamline, Ax, to define er: 




In the adloss.f routine in ADPAC \ is brought in and multiplied by, 


2 p pW x Vol 
P 2 I|W|| 2 ' 

If one multiplies by the Velocity vector, pW, the expression simplifies to 


2 W T Vol pa 
IIWII 2 


W = 2 


W x 

IIWII 


Vol pa T\^ 


Since is the unit vector tangent to W, we have 


W x _ dx 

iiwji ~ si 


which has the effect of accounting for the meridional and tangential components of the arc 


length, 


W x A h dx 

p(T IIWII - p a x m 


The enthalpy and force relation is Ah = f T A1 where distance, Al, is along the streamline 
and not axial distance. Although, the enthalpy is divided by the axial distance, Ah/ Ax, 
to distribute the force (enthalpy) evenly over the blade chord, there is an additional effect 
which must be taken into account. Namely, ensuring that the streamline length is 
properly accounted for, hence multiplying by dx/dl. By doing so, the enthalpy change is 
constant along the axial extent of the streamline, but the blade force is proportional to 
cos a. Finally, it should be noted that the units of a and f T are acceleration. 


a(LJ) 


Ah 

Ax 
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A. 4 Error Analysis 


Consider an error analysis of this loss calculation procedure. There are five areas of 
potential error 

• interpolation error (round-off). These errors may be magnified if values are 
measured at a point which is subject to oscillations. In particular, if there are 
oscillations at a blade leading edge, there may by errors in values measured there. 

• subtraction of similar sized quantities which decreases the number of significant 
digits in the result. 

• the accuracy of the relationship between relative pressure and enthalpy. 

• the approximation to AL 

• smooth vs. piecewise linear loss force. 

• There is evidence that the loss forces applied alone can introduce some swirl into a 
flow. It is best to use these forces with blade forces which ensure that a particular 
turning distribution is maintained. 


Consider first a perturbation analysis. Let w ca i c represent the calculated solution, e its 
difference from the correct solution, iv trU e — w calc. + If we evaluate the primitive solution 
variables, QQ and QQreiative and the enthalpies HI, HOI, and propagate the 
perturbations, we see that they remain first order. 


Consider next the case of differencing similar sized numbers and the loss of significant 
digits. The differences in calculating HI and HOI are of the order \v? in a term of order 
which means the differences are TiJ-M 2 , but we do this everywhere. However, when 
the total pressure loss coefficient is re-dimensionalized, it is multiplied by {Pro — P s l) 
which is total less static pressure. This difference, expressed in terms of the enthalpy 
difference (calorically perfect), is given by, 

P 0 -P = Cihfi -h^) « 

7-1 P 2 


Pq-P 

P 


-M 2 

2 


Hence for flow at M = 0.1 we lose two significant digits and at M — 0.3 we lose one 
significant digit, and very little near transonic speeds. 


The isentropic variation of pressure with enthalpy is well represented by the ideal, 
calorically perfect assumptions up until 1500° R. Beyond this point a polynomial 
representation is appropriate. The data which describes the function and from which the 
polynomial is derived as a least-squares fit, has only 4 (perhaps 5) significant digits. 
Furthermore, comparisons of the fit of the polynomial to the data suggest that the 
polynomial is accurate to 3 significant digits (more with the fn~ l dependence factored 
out). 


When modeling losses in the throughflow environment, it should be emphasized that one 
wants the Ah to calculate f T . Currently, using pressure to calculate Ah is a major detour. 
However, this is the only solution for the available data. 
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